Het belangrijkste concept in DDD dat iedereen verkeerd begrijpt

Bounded Contexts zijn het meest impactvolle concept uit Domain Driven Design, en tegelijkertijd het meest verkeerd begrepen. Een Bounded Context is een expliciete grens waarbinnen een bepaald domeinmodel geldig is. Binnen die grens heeft elk begrip een eenduidige betekenis. Buiten die grens kan hetzelfde woord iets heel anders betekenen.

Neem het woord "klant". Voor de afdeling Sales is een klant iemand met een contactpersoon, een pipeline-status en een verwachte dealwaarde. Voor Facturatie is diezelfde klant een entiteit met een btw-nummer, betalingstermijn en factuuradres. Voor Support is het iemand met een tickethistorie en een SLA-niveau.

Het is dezelfde persoon, maar drie fundamenteel verschillende modellen. Een Bounded Context maakt die grenzen expliciet.

Waarom het ertoe doet

Zonder Bounded Contexts krijg je wat Eric Evans een Big Ball of Mud noemt: een enkel, allesomvattend model dat probeert alle aspecten van het domein te vangen. Dat model wordt onvermijdelijk inconsistent, moeilijk te begrijpen en nog moeilijker te wijzigen.

Met Bounded Contexts:

  • Elk model is klein genoeg om te begrijpen. Een ontwikkelaar die aan het facturatiedomein werkt, hoeft het salesmodel niet te kennen.
  • Wijzigingen zijn gecontainerd. Een aanpassing in het salesmodel raakt het facturatiemodel niet.
  • Teams kunnen onafhankelijk werken. Elk team beheerst zijn eigen Bounded Context en kan autonoom beslissingen nemen.
  • De taal is eenduidig. Binnen elke context weet iedereen precies wat elk begrip betekent. Dit is de Ubiquitous Language in actie.

Hoe vind je de grenzen?

Dit is waar het in de praktijk lastig wordt. Er is geen algoritme dat je Bounded Contexts voor je uitrekent. Maar er zijn heuristieken:

Luister naar de taal. Als dezelfde term in verschillende delen van het bedrijf een andere betekenis heeft, is dat een sterke indicatie van een contextgrens. Event Storming is een uitstekende techniek om dit boven tafel te krijgen.

Kijk naar organisatiegrenzen. Conway's Law werkt in twee richtingen. Teams die onafhankelijk opereren hebben vaak al impliciet gescheiden contexten. Maak die grenzen expliciet.

Volg de data-eigenaarschap. Welk team is de authoritative source voor welke data? Dat team beheert de Bounded Context waarin die data leeft.

Let op waar integratie pijn doet. Als twee delen van je systeem constant in conflict zijn bij wijzigingen, probeer je waarschijnlijk twee contexten in een model te persen.

Veelgemaakte fouten

Te veel contexten. Elke Bounded Context brengt integratiekosten met zich mee. Als je tien contexten hebt met drie ontwikkelaars, heb je meer overhead dan waarde. Begin groot en splits pas als de noodzaak zich aandient.

Te weinig contexten. Het andere uiterste: alles in een monoliet proppen en hopen dat het goed komt. Als je merkt dat wijzigingen in een deel van het systeem constant onverwachte effecten hebben in een ander deel, zijn je contexten te breed.

Contexten scheiden op technische grenzen. Een Bounded Context is een domeingrens, geen technische grens. "De database-laag" of "de API-laag" zijn geen Bounded Contexts.

Integratie negeren. Bounded Contexts moeten communiceren. Definieer expliciet hoe dat gebeurt: via events, via een API, via een shared kernel. De Context Map uit DDD is hier het instrument voor.

Bounded Contexts en microservices

Een veel gehoorde vuistregel is "een microservice per Bounded Context". Dat is een redelijk startpunt, maar niet absoluut. Een Bounded Context kan intern meerdere services bevatten. En je kunt Bounded Contexts ook implementeren als modules binnen een monoliet (een modular monolith). De contextgrens is logisch; de deploymentgrens is een separate beslissing.

NForza en Domain Driven Design

Bij NForza gebruiken we DDD en Bounded Contexts al jaren in complexe domeinen. We begeleiden teams met Event Storming om domeinkennis boven water te krijgen en contextgrenzen te identificeren. Onze ervaring leert dat de juiste opdeling van je domein het verschil maakt tussen een systeem dat meegroeit met je organisatie en een systeem dat je remt.