ehoandClaude Sonnet 5
d4c5a9450a
Two components disagreed with their own story title. async.component.ts had no layer tag; add `Molecule:` to its class header, not to the Convenience: comment on the ASYNC array (that comment describes an export, not a layer, and stays as it is). breadcrumb.component.ts had `Chrome:`; rename it to `Molecule:` to match its story title. CLAUDE.md and layers.mdx both claimed `libs/beheer/ui` is Design System. The code disagrees: its story title is `Domein/Beheer/...`, because libs/beheer is a bounded context that lives under libs/ only because two apps share it. Fix the two doc lines to match the code; the story title does not change. The ticket's own tag-count check asserted 68 after the edits, but adding a new tag to async.component.ts (which had none) is a net +1 over the Chrome-to-Molecule rename (a wash) — the true post-edit count is 69. Corrected the number in the ticket text rather than deleting the mandated tag to force the wrong count. Also fixed pre-existing invalid nested-backtick markdown in the ticket's decision 4 bullets: prettier mis-rewrapped it and dropped spaces, so the phrasing was rewritten in valid CommonMark with no change in meaning. npm run ci --full passes. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
115 lines
6.2 KiB
Plaintext
115 lines
6.2 KiB
Plaintext
import { Meta } from '@storybook/addon-docs/blocks';
|
|
|
|
<Meta title="Foundations/Domain-Driven Design" />
|
|
|
|
# Domain-driven design: bounded contexts & layers
|
|
|
|
This project is **domain-driven**: the code is organised first by **bounded context**
|
|
(a business capability with its own language) and then by **layer** inside each context,
|
|
with dependencies pointing inward. The Storybook sidebar is laid out to **be** that
|
|
architecture, not just document it: **Foundations** (this curriculum) → **Design System**
|
|
(reusable, domain-free) → **Domein** (the app-local DDD contexts). If a component lives
|
|
under a context's `ui/`, or under `libs/beheer/ui`, it's in Domein; everything else in
|
|
`libs/shared/ui`/`layout` is Design System. See [Atomic design](?path=/docs/foundations-atomic-design--docs)
|
|
for the Atoms → Molecules → Organisms → Templates ladder inside Design System.
|
|
|
|
## Two apps, two shared libraries
|
|
|
|
This is a **monorepo**: two Angular projects share one backend and one shared library.
|
|
|
|
```
|
|
apps/<app>/src/app/<context>/<layer>/ — app-local bounded context
|
|
libs/<lib>/src/<layer>/ — cross-app library
|
|
```
|
|
|
|
- `apps/ssp` — the Zorgverlener self-service portal. Contexts: `auth`, `registratie`,
|
|
`herregistratie`, `brief` (letter-composition teaching slice), `showcase` (teaching
|
|
page, sanctioned to read every context in its own app — nothing imports it).
|
|
- `apps/behandelportal` — the Behandelaar backoffice (ADR-0002). Contexts: `auth`,
|
|
`behandeling`.
|
|
- `libs/shared` — the design system + kernel + generated API client. No business logic.
|
|
The base layer: depends on nothing app- or context-specific.
|
|
- `libs/beheer` — the admin/stamdata context, used identically by both apps.
|
|
|
|
`auth` is deliberately **not** shared even though today it's near-identical in both
|
|
apps — ADR-0002 models Zorgverlener/Medewerker as different `Principal` variants with
|
|
different login flows, so the two copies are expected to diverge.
|
|
|
|
**Dependencies only point inward, in one declared direction between contexts:**
|
|
|
|
```
|
|
herregistratie → registratie → libs/shared|beheer (ssp)
|
|
auth → libs/shared|beheer (ssp)
|
|
brief → libs/shared|beheer (ssp)
|
|
behandeling → libs/shared|beheer (behandelportal)
|
|
auth → libs/shared|beheer (behandelportal)
|
|
```
|
|
|
|
Never the other way — `registratie` may not import `herregistratie`, no context but
|
|
`libs/shared`/`libs/beheer` is imported by everyone, an app may not import the other
|
|
app's source, and `libs/shared` may not depend on `libs/beheer` (shared stays the base,
|
|
beheer a peer leaf).
|
|
|
|
## Five layers, one direction
|
|
|
|
| Layer | Job | Angular allowed? |
|
|
| ----------------- | ----------------------------------------- | ----------------- |
|
|
| `domain/` | business rules + data types | **No — pure TS.** |
|
|
| `application/` | coordinate state/tasks (stores, commands) | yes (signals) |
|
|
| `infrastructure/` | where data comes from (HTTP adapters) | yes (HTTP) |
|
|
| `contracts/` | wire DTOs (the FE⇄BE seam) | no |
|
|
| `ui/` | how it looks (components, pages) | yes |
|
|
|
|
`ui → application → domain`; `ui`/`layout` never import `infrastructure/` directly — they
|
|
reach data through an application store or command.
|
|
|
|
## This is enforced, not just written down
|
|
|
|
`npm run dep:check` (dependency-cruiser) fails the build on every rule above. One shared
|
|
rule _factory_ (`.dependency-cruiser.base.js`) is instantiated once per app — each app is
|
|
cruised separately against its own `tsconfig.json`, since `apps/ssp` and
|
|
`apps/behandelportal` each declare `@auth/*` pointing at a different physical directory
|
|
and a single merged tsconfig can't resolve both at once:
|
|
|
|
- `domain/` importing `@angular/*` at all (any context, either app).
|
|
- `libs/shared` importing an app feature context, or `libs/beheer` — the base layer
|
|
depends on nothing.
|
|
- `libs/beheer` importing an app feature context.
|
|
- an app importing the other app's source directly.
|
|
- `registratie/` importing `@herregistratie/*`/`@brief/*`, `auth/`/`brief/` importing a
|
|
sibling context — the cross-context direction above, one `.dependency-cruiser.<app>.js`
|
|
per app.
|
|
- `contracts/**` importing **anything** — not Angular, not an alias, not even a relative
|
|
path (ADR-0001's wire seam has to stay a pure DTO shape).
|
|
- `ui/**`/`layout/**` importing `*/infrastructure/*` — the anti-corruption boundary
|
|
(ADR-0001) stays behind a store/command, so a page can never bypass it and hand-recompute
|
|
a business rule the backend already decided.
|
|
- The generated `ApiClient` imported as a value outside an `infrastructure/` adapter
|
|
(type-only DTO imports are exempt — they grant no network access).
|
|
|
|
`showcase` gets a documented exemption from the "nothing reaches across" rule
|
|
(`showcase: null` in `.dependency-cruiser.ssp.js`) — it reads every context in its own
|
|
app, for side-by-side teaching pages. The dev-only state panel (`apps/ssp/src/app/shell/debug-state`)
|
|
reads every root store too, but needs no such exemption: it lives outside any enumerated
|
|
context, so the per-context scoping rule never applies to it in the first place.
|
|
|
|
`npm run lint` (`eslint.config.mjs`) is a separate gate — mainly the `any`-free rule —
|
|
and no longer carries the import-boundary rules above (moved to dependency-cruiser,
|
|
so they don't have to be hand-copied per context).
|
|
|
|
## The English/Dutch seam
|
|
|
|
Shared/reusable UI is named in **English** (language-agnostic: `button`, `wizard-shell`);
|
|
domain contexts are named in **Dutch** (`registratie`, `herregistratie`, `*.machine.ts`).
|
|
Pick the language by which side of the seam the code is on — it's the same seam this
|
|
sidebar's Design System/Domein split makes visible.
|
|
|
|
## See it in the sidebar
|
|
|
|
Compare a Design System primitive with the same shape reused across contexts:
|
|
|
|
- [Design System → Molecules → Application Link](?path=/story/design-system-molecules-application-link--navigatie) —
|
|
domain-free, the caller supplies heading/subtitle/cta.
|
|
- [Domein → Registratie → Aanvraag Block](?path=/story/domein-registratie-aanvraag-block--concept) —
|
|
a context-specific organism composed from Design System atoms/molecules.
|