DDD begint niet met een map `domain`
Eric Evans presenteert DDD als een verzameling patronen en definities voor werken met domeinmodellen, terwijl Martin Fowler de nadruk legt op het modelleren van complexe domeinen en een gedeelde taal tussen ontwikkelaars en domeinexperts. [1][2][4]
Een structuur `domain/application/infrastructure` maakt een applicatie dus niet automatisch DDD. Een codebase kan perfect benoemde mappen hebben en toch alleen DTO's en procedurele logica bevatten. Strategisch DDD kan ook zonder canonieke lagenstructuur worden toegepast.
Strategisch DDD en tactisch DDD werken op verschillende niveaus
Strategisch DDD gaat over het opsplitsen van een groter domein in subdomeinen en Bounded Contexts en over hun onderlinge relaties. Microsoft beschrijft domeinanalyse als het identificeren van subdomeinen en contexts, terwijl Fowler Bounded Context als centraal strategisch patroon beschouwt. [3][7]
Tactisch DDD werkt binnen één concrete context en omvat onder andere Entities, Value Objects, Aggregates en Domain Services. Microsoft maakt expliciet onderscheid tussen strategische analyse en tactische modellering. [8]
In frontend is het vaak beter om met strategisch ontwerp te beginnen en pas daarna te beslissen welke context echt een rijk tactisch model nodig heeft.
Een Bounded Context is geen technische laag
Fowler beschrijft een Bounded Context als een grens waarbinnen een model intern consistent blijft en termen eenduidig zijn. Hetzelfde begrip, zoals `Customer` of `Product`, kan in verschillende contexten terecht iets anders betekenen. [3]
Daarom zijn `frontend`, `backend`, `React app`, `route` en `micro-frontend` niet automatisch Bounded Contexts. Contextgrenzen komen voort uit domeinmodel en taal, niet uit technologie. Praktische frontend-DDD-bronnen waarschuwen voor dezelfde verwarring. [15][16]
Wanneer DDD in frontend zinvol is
| Signaal | Richting | Waarom |
|---|---|---|
| Veel veranderende bedrijfsregels | DDD | Een domeinmodel voorkomt verspreide regelimplementatie |
| Dezelfde begrippen betekenen iets anders per productgebied | DDD | Bounded Contexts ondersteunen meerdere coherente modellen |
| Meerdere teams en domeinexperts werken samen | DDD | Ubiquitous Language vermindert ambiguïteit |
| Eenvoudige CRUD en formulieren | Eenvoudigere modulariteit | De kosten van tactisch DDD kunnen hoger zijn dan de baten |
| Frontend weerspiegelt vooral een API | Eenvoudigere modulariteit | Er is weinig eigen domeinlogica aan clientzijde |
| Kleine applicatie met één coherent domein | Eenvoudigere modulariteit | Extra grenzen en lagen kunnen weinig waarde leveren |
Het sterkste signaal is complexe en vaak veranderende bedrijfslogica aan clientzijde: configurators, meerstapsprocessen, pricing, rechten, statusovergangen, workflows of verschillende modellen van hetzelfde begrip in verschillende productgebieden.
DDD is ook waardevol wanneer meerdere teams aan een groot product werken en dezelfde woorden in verschillende gebieden iets anders betekenen. Bounded Contexts zijn juist bedoeld om meerdere coherente modellen te beheren. [3]
DDD Crew adviseert eerst het domein te begrijpen, strategisch belangrijke subdomeinen te identificeren, vervolgens de verantwoordelijkheden van Bounded Contexts te definiëren en pas daarna het model te coderen. [10]
Wanneer DDD overengineering wordt
Als het frontend vooral data ophaalt, toont, formulieren bewerkt en eenvoudige CRUD-commando's verstuurt zonder noemenswaardige bedrijfslogica aan clientzijde, lost de volledige set tactische DDD-patronen meestal geen echt probleem op.
Microsoft stelt expliciet dat in een eenvoudige CRUD-context een anemisch datamodel voldoende kan zijn en dat complexere DDD-patronen niet altijd de kosten waard zijn. Een rijk model wordt relevanter bij veel veranderende bedrijfsregels. [9]
Hetzelfde criterium hoort in frontend te gelden: architecturale verfijning moet passen bij domeincomplexiteit, niet bij technische ambitie.
Ubiquitous Language hoort ook zichtbaar te zijn in UI-code
Ubiquitous Language is een gedeelde, precieze taal die ontwikkelaars en domeinexperts rond het model opbouwen. Fowler benadrukt dat deze taal moet evolueren wanneer het domeinbegrip groeit. [4]
In frontend zouden namen van use cases, acties, types, modules, schermen en states daarom bedrijfswoorden moeten gebruiken wanneer ze domeingedrag beschrijven.
Als de business `approveApplication` zegt terwijl de code `setFlag2` of `handleData` gebruikt, verliest de code zijn rol als duidelijke representatie van de domeintaal.
Organiseer een groot frontend rond domeinen, niet alleen bestandstypen
Fowler merkt op dat een top-level structuur `view/model/data` voor kleine systemen kan werken, maar dat grotere applicaties beter top-level domeinmodules kunnen hebben die intern hun eigen lagen bevatten. [5]
De actuele Nx-documentatie volgt een vergelijkbare richting: mappen kunnen domein-ownershipgrenzen vormen en libraries binnen een domein kunnen worden geclassificeerd als `feature`, `ui`, `data-access` en `util`. [12]
Een praktische structuur kan dus `libs/orders/...`, `libs/billing/...` en `libs/identity/...` gebruiken in plaats van één globale boom `components/`, `services/`, `models/`.
Scheid presentatiegedrag van domeingedrag
Fowler beschrijft de scheiding tussen presentatie, domeinlogica en data access als effectieve modularisatie. Hij merkt ook op dat UI-code vaak moeilijker te testen is, waardoor domeinlogica buiten presentatie extra waarde heeft. [5][6]
Een frontendcomponent hoort vooral te renderen, UI-events af te handelen en bewerkingen te delegeren. Regels zoals of een bestelling geannuleerd mag worden, hoe korting wordt berekend of welke statusovergang geldig is, verdienen een expliciete plek buiten JSX, templates of componentklassen.
Dit verbiedt presentatielogica niet. View-validatie, zichtbaarheid, lokale focus en animatie zijn iets anders dan bedrijfsregels.
Praktische lagen binnen één frontendcontext
| Laag | Verantwoordelijkheid | Voorbeelden |
|---|---|---|
| presentation / ui | Rendering en interfacegedrag | components, routes, view state |
| application | Coördinatie van use cases | commands, use cases, orchestration |
| domain | Domeinregels, begrippen en invarianten | entities, value objects, policies |
| infrastructure / data-access | Technische integraties | HTTP, storage, SDKs, mappers |
DDD schrijft geen verplichte mapstructuur voor. De scheiding `presentation`, `application`, `domain` en `infrastructure` is een praktische interpretatie van verantwoordelijkheidsseparatie, geen formele eis van Evans. [1][5]
De domain-laag kan frameworkonafhankelijke regels, begrippen en gedrag bevatten; application coördineert use cases; infrastructure adapteert HTTP, storage en externe SDK's; presentation bevat componenten, routing en puur UI-state.
API-model en frontend-domeinmodel hoeven niet identiek te zijn
Een Bounded Context kan een eigen model van een begrip hebben en verschillende contexten kunnen tussen representaties mappen. Fowler gebruikt `Customer` en `Product` als typische voorbeelden van termen die per context anders kunnen betekenen. [3]
Een backend-DTO hoeft daarom niet rechtstreeks ieder component binnen te komen. Een mapper of adapter kan het transportcontract omzetten naar het model van een specifieke frontendcontext.
Deze grens is vooral nuttig wanneer een API meerdere clients bedient, legacy is, meerdere domeinen combineert of onafhankelijk evolueert. Voor een eenvoudige CRUD-endpoint kan een extra mappinglaag overbodig zijn.
Entities, Value Objects en Aggregates: selectief gebruiken
DDD onderscheidt onder andere Entities, Value Objects, Services en Aggregates. Fowler noemt ze als onderdeel van Evans' DDD-vocabulaire, terwijl Microsoft aggregates beschrijft als tactisch patroon voor modelconsistentie. [2][8]
Het frontend moet het backendmodel niet één op één kopiëren om dezelfde klassen te hebben. Een Value Object kan nuttig zijn voor `Money`, `DateRange` of `Email` wanneer het echte invarianten bewaakt. Een Aggregate is zinvol wanneer de client daadwerkelijk consistentievoorwaarden moet bewaken.
Als een type alleen tabeldata voor rendering is, kan een eenvoudig TypeScript-type beter zijn dan Entity, Factory, Repository en Service.
UI-state is niet hetzelfde als domeinstate
React behandelt state-organisatie als ontwerpvraag en adviseert redundante of gedupliceerde state te vermijden. Dat is nuttige technische begeleiding, maar reducers, stores of signals creëren op zichzelf geen domeinmodel. [14]
State zoals `isModalOpen`, actieve tab of scrollpositie hoort bij presentatie. De levenscyclus van een order, toegestane procesovergangen of configuratieregels kunnen tot het domeinmodel behoren.
Deze scheiding voorkomt globale stores waarin serverdata, bedrijfslogica en UI-details door elkaar lopen.
Grenzen moeten worden afgedwongen, niet alleen beschreven
Nx laat projecttags en declaratieve dependency constraints definiëren, bijvoorbeeld om imports tussen scopes of librarytypes te blokkeren. `@nx/enforce-module-boundaries` kan imports tijdens linting controleren. [11]
Nx ondersteunt ook meerdere tagdimensies, zodat `scope`, librarytype, stabiliteit of client/server-aspecten apart gemodelleerd kunnen worden. [13]
Frontend-DDD-beslissingen kunnen zo CI-regels worden: `billing` importeert geen interne delen van `identity`, `ui` hangt niet af van `data-access` en `domain` blijft frameworkonafhankelijk.
Frontend en backend kunnen een domein delen zonder identieke modellen
Een Bounded Context is een model- en taalgrens en hoort daarom niet automatisch langs de netwerkgrens tussen browser en server te lopen. Praktische frontend-DDD-bronnen benadrukken dat contexts technische lagen kunnen doorsnijden en gezamenlijk door frontend en backend worden geïmplementeerd. [15][16]
De clientrepresentatie kan toch verschillen van de serverrepresentatie door andere behoeften rond interactie, lokale state en presentatie. Belangrijk zijn correcte semantiek en expliciete mapping, niet het kopiëren van klassen.
Een micro-frontend hoeft ook niet alleen te ontstaan omdat er een Bounded Context bestaat. Domeingrens en deploymentgrens zijn verschillende ontwerpbeslissingen.
Testbaarheid is een sterk argument voor geïsoleerde domeinlogica
Fowler noemt testbaarheid als voordeel van scheiding tussen presentatie en domein. Logica buiten de UI kan worden getest zonder componenten te renderen of van interfacedetails afhankelijk te zijn. [5][6]
In frontend maakt dit snelle tests mogelijk van regels, Value Objects, use cases en statusovergangen als gewoon TypeScript of JavaScript. Componenttests blijven nodig, maar hoeven niet de enige plek te zijn waar bedrijfsregels worden gevalideerd.
Een waarschuwingssignaal is dat iedere wijziging in een bedrijfsregel het mounten van een compleet component en mocks voor router, store, HTTP en browser-API's vereist.
DDD invoeren in een bestaand frontend zonder grote rewrite
DDD Crew adviseert een iteratief proces: domein begrijpen, belangrijke subdomeinen bepalen, verantwoordelijkheden van Bounded Contexts definiëren en daarna het model coderen. [10]
In een bestaand frontend is het veiliger één problematisch bedrijfsgebied te kiezen, taal en grens vast te leggen, presentatie van regels te scheiden, de publieke module-API te definiëren en daarna pas andere features te migreren.
Niet de hele applicatie hoeft te worden gemigreerd. DDD kan worden toegepast waar bedrijfscomplexiteit de modellering terugverdient, terwijl eenvoudige gebieden lichte featuremodules blijven.
- Begin met een bedrijfsprobleem, niet met mappen.
- Identificeer termen, regels en dubbelzinnige begrippen.
- Definieer één Bounded Context en zijn publieke contract.
- Scheid domeinregels van componenten en transport-DTO's.
- Voeg alleen tactische patronen toe die concrete complexiteit oplossen.
- Leg grenzen vast als lint- of CI-regels.
- Meet dependencies, cycles, regressies en kosten van cross-cutting wijzigingen.
- Migreer eenvoudige CRUD-gebieden niet alleen voor architecturale symmetrie.
