Domein Model, glossary naar DDD, Design thinking en meer

Deze workshop behandelt het opstellen van een domein model bij de start van een software development project. Het domein model past goed bij methoden als Domain-Driven Design (DDD), maar sluit ook aan bij Design Thinking, die bv. ook Media Design professionals gebruiken. Beide benadrukken het belang van eerst een probleem goed begrijpen voordat je naar oplossingen kijkt. Je leert het onderscheid tussen probleemdomein en oplossingsdomein, en hoe je een domein model kunt vertalen naar software-architectuur. Tussendoor komt ook ethische overweging aan bod: niet alles wat je kunt opslaan, moet je ook opslaan (privacy-by-design).

We behandelen een uitgebreide casus over een bibliotheeksysteem met verschillende varianten van domeinmodellen als voorbeeld. Belangrijk: Pas deze theorie toe op je eigen projectcasus. Sectie 1 geeft een inleiding over het domein model en de glossary, sectie 2 behandelt het conceptuele onderscheid tussen probleem- en oplossingsdomein, sectie 3 gaat over datatypes en terminologie, sectie 4 behandelt subdomeinen en bounded contexts, sectie 5 bevat concrete voorbeelden van domeinmodellen voor de bibliotheek casus, sectie 6 geeft kwaliteitscriteria in de vorm van een checklist, en sectie 7 biedt verdieping voor wie verder wil lezen.

"If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and five minutes thinking about solutions." — Albert Einstein

1. Inleiding

Bij de start van het project (kick-off en eerste sprint) is het belangrijk om het domein goed te begrijpen. Daarom wordt er in de eerste sprint een domein model opgesteld, samen met een glossary (woordenlijst).

Een domein model is een visuele representatie van de belangrijkste concepten, entiteiten en hun relaties binnen het probleemdomein. Het is primair een communicatiemiddel, niet een tussenstap in het ontwerp. Larman (2004) noemt het ook wel een "visual dictionary". Het helpt het team om een gedeeld begrip te ontwikkelen van de businesslogica. Na validatie met niet-technische stakeholders vormt het de basis voor de software-architectuur. De glossary is een tabel met belangrijke termen uit het domein en hun uitleg, wat helpt om ambiguïteit te voorkomen en een gemeenschappelijke taal te ontwikkelen.

Belangrijk: Domeinmodellen moeten klein en overzichtelijk blijven. In Larman's boek staan alleen maar kleine diagrammen - dit is bewust, niet omdat Larman niet kan modelleren. Modellen zijn ook voor mensen met beperkte (cognitieve) capaciteit.

Als het model te groot wordt, kun je het opsplitsen in subdomeinen volgens Domain-Driven Design (DDD) principes. Studenten die DDD patterns zoals Aggregate hebben gehad, kunnen hier ook naar vooruit denken bij het opsplitsen in subdomeinen. Een domein model ter grootte van een A4-vel is de maximale grootte om te lezen en te bespreken.

Figuur 1: Domain-Driven Design (DDD) Strategic Design Patterns - Ubiquitous Language, Bounded Context en Context Mapping (Lambrych, 2024).

Zie ook sectie 4 voor uitleg over subdomeinen en bounded contexts, en criterium DM-6 voor meer informatie over Context Mapping.

Let op: Het domein model bevindt zich in het probleemdomein, niet in het oplossingsdomein. Het gaat om de concepten en relaties in de business/wereld, niet om software classes of models in de code. Het domein model helpt om het probleem te begrijpen voordat je naar de oplossing (software) kijkt. Uiteraard is er wel een relatie tussen het probleemdomein en het oplossingsdomein te maken. In de Realisatie fase kun je nog wel een domain layer met models/entities maken en een DB datamodel opstellen (bijvoorbeeld in je Software Guidebook), waarin stukken uit het domein model terug te vinden zijn.

2. Probleem- vs. oplossingsdomein - Subset relatie

Het oplossingsdomein is vaak een subset van het probleemdomein (zie verzamelingenleer: een subset is een deelverzameling waarbij alle elementen van de subset ook in de oorspronkelijke verzameling zitten). Dit betekent dat niet alle concepten en attributen uit het probleemdomein automatisch in het oplossingsdomein terechtkomen.

2.1 Voorbeeld: Klant entiteit

Bijvoorbeeld, een Klant in het probleemdomein heeft mogelijk veel meer eigenschappen dan nodig zijn voor de software:

• Naam en klantnummer → wel nodig in oplossingsdomein
• Favoriet boekentype (bijvoorbeeld "science fiction" of "thriller") → mogelijk niet nodig voor MVP, maar kan later worden toegevoegd voor personalisatie
• Speelcomputer type (bijvoorbeeld "Nintendo", "PlayStation" of "PC") → bepaalt welk type games de klant typisch leent, maar mogelijk niet nodig voor eerste versie
• Geslacht (hij/zij/anders) → niet nodig voor functionaliteit, en vanuit privacy by design principe slaan we dit niet op tenzij er een goede reden is (bijvoorbeeld voor gepersonaliseerde aanhef in brieven/e-mails bij overschreden leenlimiet)

Deze "kandidaatvelden" kunnen in latere sprints/releases worden toegevoegd via extra features, maar worden bewust weggelaten in de eerste versie om het model simpel te houden en privacy te beschermen.

2.2 Ethische overwegingen: wenselijkheid van data opslag

Hoewel met de uitbreiding van opslagcapaciteit jarenlang ook veelal zoveel mogelijk data in applicaties lieten opslaan, met het motto "baat het niet dan schaadt het niet" of "We zien later wel wat we met de data doen" is dit sinds een aantal jaar aan het veranderen. Bij het kiezen wat je wel of niet implementeert, speelt niet alleen technische haalbaarheid of functionele noodzaak een rol, maar ook ethische overwegingen. Dit sluit aan bij de HAN speerpunten slim, schoon en sociaal:

• Slim: Technisch gezien kun je veel data verzamelen en analyseren, maar dat betekent niet dat je dat ook moet doen
• Schoon: Door alleen noodzakelijke data op te slaan, voorkom je onnodige complexiteit en potentieel misbruik
• Sociaal: Het beschermen van privacy en voorkomen van discriminatie en profilering is een maatschappelijke verantwoordelijkheid

Dus niet alles wat je kunt meten, moet je ook willen opslaan. Denk kritisch na over de gevolgen van het verzamelen en gebruiken van data, vooral wanneer dit kan leiden tot profilering of discriminatie van gebruikers.

Figuur 2: Probleemdomein vs Oplossingsdomein — het oplossingsdomein bevat een subset van de concepten uit het probleemdomein (Lambrych, 2024).

NB: We hebben de inkleuring in figuur 2 aangepast in lijn met Figuur 1: geel voor probleemdomein, groen voor oplossingsdomein.

@startuml
!theme plain
skinparam classAttributeIconSize 0
skinparam packageStyle rectangle

' Kleuren uit Lambrych figuur
skinparam package {
  BackgroundColor<<problem>> #FFF1AD
  BackgroundColor<<solution>> #C1F6C9
  BorderColor #666666
}

skinparam class {
  BackgroundColor<<problem>> #FFF1AD
  BackgroundColor<<solution>> #C1F6C9
  BorderColor #444444
}

package "Bibliotheek" <<problem>> {
  class Klant <<problem>> {
    - naam
    - klantnummer
    - favorietBoekentype
    - speelcomputerType
    - geslacht
  }

  class Uitleenitem <<problem>> {
    - titel
    - auteur
    - isbn
    - aantalPaginas
    - taal
    - uitgever
  }

  class Reservering <<problem>> {
    - reserveringsnummer
    - reserveringsdatum
    - redenVoorReservering
    - voorkeursdatum
  }

  Klant "1" --> "*" Reservering : maakt
  Reservering "*" --> "*" Uitleenitem : bevat
}

package "Bibliotheek" <<solution>> {
  class Klant <<solution>> {
    - id: Long
    - naam: String
    - klantnummer: String
  }

  class Uitleenitem <<solution>> {
    - id: Long
    - titel: String
    - isbn: String
  }

  class Reservering <<solution>> {
    - id: Long
    - reserveringsnummer: String
    - reserveringsdatum: LocalDate
    - klantId: Long
  }

  Klant "1" --> "*" Reservering : maakt
  Reservering "*" --> "*" Uitleenitem : bevat
}

note bottom of "Bibliotheek"
  Links: Probleemdomein - alle concepten
  uit de echte wereld/business

  Rechts: Oplossingsdomein - subset,
  alleen wat nodig is voor de MVP
end note

@enduml

Glossary - Klant: Probleemdomein vs. Oplossingsdomein

Tabel: Vergelijking attributen Klant in probleemdomein vs. oplossingsdomein. Attributen met ✅ komen in de MVP, attributen met ❌ zijn kandidaten voor latere releases, en ⚠️ geeft privacy-gevoelige attributen aan.

Opdracht: Identificeer voor je eigen projectcasus minimaal drie entiteiten uit het probleemdomein. Voor elke entiteit, maak een lijst van attributen die:

• Wel nodig zijn in het oplossingsdomein (voor de MVP)
• Mogelijk niet nodig zijn voor de MVP, maar later kunnen worden toegevoegd
• Ethisch niet wenselijk zijn om op te slaan (bijvoorbeeld vanwege privacy by design)

2.3 Design Thinking en de Double Diamond

Hoewel beginnende ICT'ers het belang van 'stilstaan bij het probleem' op basis van een quote van Einstein wellicht wel inzien (Figuur X), is in de praktijk toch de neiging om snel de code in te duiken, omdat hier ook nog allerlei technische uitdagingen en onbekendheden zijn. En ook omdat het probleemdomein heel simpel is. Een simpele opdracht als het 'FizzBuzz' drankspelletje, priemgetallen berekenen of de oppervlakte van verschillende figuren als een vierkant en driehoek berekenen, of een bekende casus in het onderwijs zoals een onderwijsadministratie met Student-Docent-Course-Cijfer e.d. Kortom 'academische problemen' of wellicht zelfs 'speelgoed domeinen' te noemen. In de praktijk zijn dit allemaal opgeloste problemen en is er vooral geld te verdienen als ICT met applicaties in complexe domeinen zoals het Verzekeringsdomein, of 'netbeheer' van electrische netwerken met heel veel business of organisatie logica.

Om nog even extra stil te staan is een mooie model dat vanDouble Diamond model uit Design Thinking. De kern hierin is een duidelijk onderscheid tussen probleemdomein en oplossingsdomein komt overeen met het

Dit model beschrijft twee fasen van divergeren (verbreden) en convergeren (vernauwen):

1. Probleemdomein (Problem Space) — de eerste diamond:

   • Discover (divergeren): Verken het probleem breed, verzamel informatie
   • Define (convergeren): Definieer het kernprobleem
   • ICT-documenten: Domein model, glossary, requirements, SRS/user stories, (high level) use case model, of in Software Guidebook: Constraints, Context en C4 Context diagram

2. Oplossingsdomein (Solution Space) — de tweede diamond:

   • Develop (divergeren): Verzin verschillende oplossingen
   • Deliver (convergeren): Kies en implementeer de beste oplossing
   • ICT-documenten: Software Architecture Document (SAD), Software Design Document (SDD), fully dressed use cases, of in Software Guidebook: Functional Overview, Code, Data, Deployment etc.

Let op: Er zijn verschillende varianten van design thinking. De Double Diamond gebruikt 4 fasen (Discover, Define, Develop, Deliver), terwijl andere modellen zoals die van Stanford d.school 5 fasen gebruiken: Empathize, Define, Ideate, Prototype en Test. Beide modellen hebben hetzelfde doel: eerst het probleem goed begrijpen voordat je naar oplossingen kijkt.

Tip: Zie voor meer informatie de officiële Double Diamond pagina van de Design Council (z.d.), waar ook een korte video staat waarin Jonathan Ball (een van de oorspronkelijke bedenkers) het model uitlegt.

Figuur 3: Double Diamond model - Probleemdomein (Problem Space) en Oplossingsdomein (Solution Space) (Gupta, 2019)

De take away van dit verhaal is dat je bij het maken van software een goede balans moet vinden tussen het probleem voldoende goed begrijpen (zodat je niet een ander probleem oplost dan de opdrachtgever bedoelde) en pragmatisch een zo simpel mogelijke oplossing realiseren (zodat je niet strandt in analysis paralysis of accidental complexity).

"Everything should be made as simple as it can be, but not simpler." — Albert Einstein

Opdracht: Verzin voor deze casus nog enkele velden uit het probleemgebied die wel in het probleemdomein voorkomen maar niet in het oplossingsdomein.

💡 Tip: Denk eerst zelf na voordat je de antwoorden bekijkt! Sleep met je muis over het blok hieronder (of tik en houd ingedrukt op mobiel) om de voorbeelden te zien.

Voorbeelden voor verschillende entiteiten

3. Datatypes in domeinmodellen

Datatypes opgeven bij de attributen (zoals String, Date, etc.) zijn optioneel in een domeinmodel. Op dit detailniveau hoef je nu nog niet na te denken, deze denk je later uit en voeg je toe).

Opdracht: Voor je eigen projectcasus: kies één entiteit uit je domein model en bepaal of je datatypes wilt toevoegen. Bedenk ook of er concepten zijn waar je twijfelt of het een aparte entiteit of attribuut (van een entiteit) moet zijn. Leg uit waarom.

Opmerking: Als je twijfelt of iets een object (klasse/entiteit) moet worden of een attribuut, kies dan bij twijfel voor een klasse/entiteit. Dit maakt het model expliciet en voorkomt dat je later belangrijke concepten mist.

4. Subdomein vs. Bounded Context vs. Microservice

Volgens Evans (2003):

• Een subdomein is een deel van het probleemdomein (bijvoorbeeld "Orderbeheer" of "Voorraadbeheer").
• Een bounded context is een conceptueel/architecturaal concept in het oplossingsdomein - het is een context waarin een bepaald domeinmodel geldig is. Een bounded context kan worden geïmplementeerd als een microservice, maar dat hoeft niet (het kan ook een module in een monoliet zijn, of meerdere microservices).
• Een microservice is een deployment/technisch concept - een zelfstandig deploybare service. Een bounded context kan je implementeren als één of meerdere microservices.

De relatie tussen subdomeinen en bounded contexts is dat een subdomein vaak wordt gemapped naar een bounded context in de oplossing. Maar dit is niet per se een 1-op-1 relatie; één bounded context kan meerdere subdomeinen bevatten, of één subdomein kan over meerdere bounded contexts worden verdeeld.

Opdracht: Voor je eigen projectcasus: bepaal of je domein model groot genoeg is om op te splitsen in subdomeinen. Als je model klein is (past op één A4), hoef je dit niet te doen. Als je model groter wordt, identificeer dan minimaal twee subdomeinen en leg uit waarom je deze splitsing maakt.

5. Voorbeeld domein model - Bibliotheek casus

Hieronder staan twee varianten van een domein model voor een bibliotheeksysteem: een initiële (eenvoudige) versie (Figuur 4) en een uitgebreide versie (Figuur 5). Je kunt deze visualiseren met de PlantUML Online Server of met de VS Code PlantUML Extension.

Tip: Bij alle zeven diagrammen in deze les staat de PlantUML broncode in een uitklapbaar blok. Dit is zodat je de code kunt kopiëren en aanpassen voor je eigen projectcasus.

5.1 Initiële versie (eenvoudig)

Deze versie bevat alleen de basisconcepten en is geschikt om te starten met het domeinmodel.

Figuur 4: Initiële domein model voor het bibliotheeksysteem met basisconcepten.

@startuml
!theme plain
skinparam classAttributeIconSize 0

class Klant {
  - naam
  - klantnummer
}

class Reservering {
  - reserveringsnummer
  - reserveringsdatum
}

class Uitleenitem {
  - titel
  - auteur
  - isbn
  - jaar van uitgifte
}

class Categorie {
  - naam
}

Klant "1" --> "*" Reservering : maakt
Reservering "1" --> "*" Uitleenitem : bevat
Uitleenitem "*" --> "1" Categorie : heeft

note right of Klant
  Een klant kan meerdere
  reserveringen maken
end note

note right of Reservering
  Een reservering kan
  meerdere items bevatten
end note

note right of Uitleenitem
  Beschrijving van een item
  (bijv. "Harry Potter deel 1").
  ISBN en jaar alleen voor boeken.
end note

note right of Categorie
  Voorbeelden: boek, game,
  stripboek
end note
@enduml

Glossary - Initiële versie

5.2 Uitgebreide versie

Deze versie bevat meer detail en maakt onderscheid tussen beschrijvingen en fysieke exemplaren, en voegt entiteiten toe voor Auteur en Conditie.

Figuur 5: Uitgebreide domein model met onderscheid tussen beschrijvingen en fysieke exemplaren.

@startuml
!theme plain
skinparam classAttributeIconSize 0

class Klant {
  - naam
  - klantnummer
}

class Reservering {
  - reserveringsnummer
  - reserveringsdatum
  - ophaaldatum
  - inleverdatum
}

class Uitleenitem {
  - titel
  - isbn
  - jaar van uitgifte
}

class Auteur {
  - naam
}

class Exemplaar {
  - exemplaarnummer
  - aanschafdatum
}

class Conditie {
  - naam
}

class Categorie {
  - naam
}

Klant "1" --> "*" Reservering : maakt
Reservering "1" --> "1" Exemplaar : bevat
Exemplaar "1" --> "1" Uitleenitem : is van
Exemplaar "1" --> "1" Conditie : heeft
Uitleenitem "*" --> "1" Categorie : heeft
Uitleenitem "1" --> "*" Exemplaar : heeft
Uitleenitem "*" --> "*" Auteur : geschreven door

note right of Klant
  Een klant kan meerdere
  reserveringen maken
end note

note right of Reservering
  Een reservering verwijst
  naar een specifiek exemplaar.
  Reserveringsdatum: wanneer gemaakt.
  Ophaaldatum: deadline voor ophalen.
  Inleverdatum: wanneer ingeleverd.
end note

note right of Uitleenitem
  Beschrijving van een item
  (bijv. "Harry Potter deel 1").
  Kan meerdere exemplaren hebben.
  ISBN en jaar alleen voor boeken.
end note

note right of Exemplaar
  Fysiek exemplaar dat
  daadwerkelijk uitgeleend wordt
end note

note right of Conditie
  Voorbeelden: als nieuw,
  veelgebruikt, beschadigd
end note

note right of Categorie
  Voorbeelden: boek, game,
  stripboek
end note
@enduml

Glossary - Uitgebreide versie

5.3 Dataklassen in het oplossingsdomein

Het domeinmodel hierboven bevindt zich in het probleemdomein - het gaat om de concepten en relaties in de business/wereld. Larman's domeinmodel is statisch en bevat meestal geen methodes. In het oplossingsdomein (de software) worden deze concepten geïmplementeerd als OO classes met specifieke datatypes en methodes. Martin Fowler's domain model bevindt zich in het oplossingsdomein en bevat wel methodes die dynamisch gedrag representeren (hoewel een class diagram nog steeds een statisch UML diagram is - binnen de UML diagram is een UML sequence diagram voor het dynamische gedrag tonen (een bepaalde sequentie van methode aanroepen op runtime)).

Terminologie: In het oplossingsdomein worden de classes soms ook wel "Business Class Diagram" genoemd, maar de term "Domein" is generieker van 'business', want omvat ook organisaties die niet per se tot het bedrijfsleven worden gerekend, zoals overheid, non-profit organisaties, of educatieve instellingen. Daarom gebruiken we liever de term "Domein".

Recap verwarrende terminologie — "domein model" in twee betekenissen:

De term "domein model" wordt helaas voor twee verschillende dingen gebruikt. Deze workshop gaat vooral over die van Craig Larman, maar de term kan verwarrend zijn, omdat de 2e soort (degene die Martin Fowler gebruikt) WEL degelijk in het oplossingsdomein zit:

1. Larman's domein model (probleemdomein): Een communicatiemiddel voor stakeholders, zonder technische details. Dit is wat we in sectie 2 bespraken als een subset van het probleemdomein dat naar het oplossingsdomein gaat.

2. Fowler's domain model (oplossingsdomein): De entiteiten/models in je code met business logica — de "domain layer" in een layered architecture. Dit is wat je in frameworks als Spring Boot of .NET terugziet als @Entity classes en/of models in een model/ folder e.d. Idealiter voeg je in deze models ook methodes toe naast de attributen, om echt Object Oriented te programeren: data+methodes, als je alle methodes voor domein logica alleen in services stopt krijg je een anemic domain model (Fowler, 2003) (wel geschikt voor simpele CRUD applicaties, maar typisch NIET voor complex 'core domain' met DDD aanpak i.p.v. CRUD)¹.

De subset-relatie geldt voor de domain layer: niet alle concepten uit het probleemdomein worden geïmplementeerd. Maar tegelijkertijd bevat de complete applicatie juist méér dan het probleemdomein: Controllers, Repositories, Services, DTOs, en technische attributen zoals id en createdAt. Deze extra classes vallen echter in andere lagen (Application, Infrastructure) en maken geen deel uit van de domain layer.

Kortom: de domain layer is een subset van het probleemdomein, maar de totale applicatie is een uitbreiding. In een UML klassendiagram van alleen de domain layer laat je de technische classes weg; in een compleet klassendiagram van de hele applicatie komen ze juist wel voor.

Let op: Figuur 6 toont een voorbeeld van hoe je het probleemdomein kunt vertalen naar het oplossingsdomein. In de praktijk kunnen er nog extra technische attributen bijkomen (zoals id, createdAt, updatedAt) en kunnen relaties worden geïmplementeerd als foreign keys of referenties. Ook komen er in het oplossingsdomein classes zoals Controllers en Repositories bij, maar deze vallen in een andere laag dan de Domein laag (bijvoorbeeld de Application laag of Infrastructure laag volgens layered architecture).

Figuur 6: Dataklassen in het oplossingsdomein met OO datatypes en methodes.

@startuml
!theme plain
skinparam classAttributeIconSize 0

class Klant {
  - id: Long
  - naam: String
  - klantnummer: String
  + maakReservering(exemplaar: Exemplaar): Reservering
  + getActieveReserveringen(): List<Reservering>
}

class Reservering {
  - id: Long
  - reserveringsnummer: String
  - reserveringsdatum: LocalDate
  - ophaaldatum: LocalDate
  - inleverdatum: LocalDate
  - klantId: Long
  - exemplaarId: Long
  + isOpgehaald(): Boolean
  + isIngeleverd(): Boolean
  + haalOp(): void
  + leverIn(): void
}

class Uitleenitem {
  - id: Long
  - titel: String
  - isbn: String?
  - jaarVanUitgifte: Integer?
  - categorieId: Long
  + getBeschikbareExemplaren(): List<Exemplaar>
  + heeftBeschikbaarExemplaar(): Boolean
  + voegAuteurToe(auteur: Auteur): void
}

class Auteur {
  - id: Long
  - naam: String
  + getGeschrevenItems(): List<Uitleenitem>
}

class Exemplaar {
  - id: Long
  - exemplaarnummer: String
  - aanschafdatum: LocalDate
  - uitleenitemId: Long
  - conditieId: Long
  + isBeschikbaar(): Boolean
  + updateConditie(conditie: Conditie): void
  + getLeeftijd(): int
}

class Conditie {
  - id: Long
  - naam: String
}

class Categorie {
  - id: Long
  - naam: String
  + getItems(): List<Uitleenitem>
}

Klant "1" --> "*" Reservering
Reservering "1" --> "1" Exemplaar
Exemplaar "1" --> "1" Uitleenitem
Exemplaar "1" --> "1" Conditie
Uitleenitem "*" --> "1" Categorie
Uitleenitem "1" --> "*" Exemplaar
Uitleenitem "*" --> "*" Auteur : many-to-many

note right of Reservering
  Foreign keys: klantId, exemplaarId
end note

note right of Uitleenitem
  isbn en jaarVanUitgifte
  zijn nullable (alleen voor boeken)
end note

note right of Exemplaar
  Foreign keys: uitleenitemId, conditieId
end note
@enduml

5.4 Subdomeinen: Uitlenen en Collectie onderhoud

Wanneer een domeinmodel te groot wordt, kun je het opsplitsen in subdomeinen volgens Domain-Driven Design (DDD) principes. Hieronder wordt het bibliotheeksysteem opgesplitst in twee subdomeinen: Uitlenen (Figuur 7) en Collectie onderhoud (Figuur 8).

5.4.1 Subdomein: Uitlenen

Dit subdomein bevat alle concepten die nodig zijn voor het uitlenen van items aan klanten.

Figuur 7: Subdomein Uitlenen — concepten voor het uitlenen van items aan klanten.

@startuml
!theme plain
skinparam classAttributeIconSize 0

class Klant {
  - naam
  - klantnummer
}

class Reservering {
  - reserveringsnummer
  - reserveringsdatum
  - ophaaldatum
  - inleverdatum
}

class Uitleenitem {
  - titel
  - isbn
  - jaar van uitgifte
}

class Auteur {
  - naam
}

class Exemplaar {
  - exemplaarnummer
  - aanschafdatum
}

class Conditie {
  - naam
}

class Categorie {
  - naam
}

Klant "1" --> "*" Reservering : maakt
Reservering "1" --> "1" Exemplaar : bevat
Exemplaar "1" --> "1" Uitleenitem : is van
Exemplaar "1" --> "1" Conditie : heeft
Uitleenitem "*" --> "1" Categorie : heeft
Uitleenitem "1" --> "*" Exemplaar : heeft
Uitleenitem "*" --> "*" Auteur : geschreven door

note right of Klant
  Een klant kan meerdere
  reserveringen maken
end note

note right of Reservering
  Een reservering verwijst
  naar een specifiek exemplaar.
  Reserveringsdatum: wanneer gemaakt.
  Ophaaldatum: deadline voor ophalen.
  Inleverdatum: wanneer ingeleverd.
end note

note right of Conditie
  In dit subdomein is conditie
  statisch - wordt niet bijgewerkt
  tijdens het uitlenen
end note
@enduml

5.4.2 Subdomein: Collectie onderhoud

Dit subdomein bevat alle concepten die nodig zijn voor het beheren en onderhouden van de collectie. In dit subdomein heeft een exemplaar een status 'Uitgeleend' (boolean) en is conditie dynamisch - het kan worden bijgewerkt door een boekkeurder. Klanten komen niet voor in dit subdomein.

Figuur 8: Subdomein Collectie onderhoud — concepten voor het beheren en onderhouden van de collectie.

@startuml
!theme plain
skinparam classAttributeIconSize 0

class Boekkeurder {
  - naam
  - medewerkernummer
  + keurAf(exemplaar: Exemplaar): void
  + bestelBij(uitleenitem: Uitleenitem): void
}

class Uitleenitem {
  - titel
  - isbn
  - jaar van uitgifte
  - aantalUitleningen
}

class Exemplaar {
  - exemplaarnummer
  - aanschafdatum
  - uitgeleend: Boolean
}

class Conditie {
  - naam
}

class ConditieInspectie {
  - inspectiedatum
  - opmerkingen
}

class CollectieUitwisseling {
  - uitwisselingsdatum
  - andereBibliotheek
  - aantalItems
}

class AndereBibliotheek {
  - naam
  - locatie
}

Boekkeurder "1" --> "*" ConditieInspectie : voert uit
ConditieInspectie "1" --> "1" Exemplaar : inspecteert
ConditieInspectie "1" --> "1" Conditie : bepaalt
Boekkeurder "*" --> "*" Uitleenitem : bestelt
Exemplaar "1" --> "*" ConditieInspectie : heeft
Exemplaar "1" --> "1" Uitleenitem : is van
Uitleenitem "1" --> "*" Exemplaar : heeft
Exemplaar "1" --> "1" Conditie : heeft
Boekkeurder "1" --> "*" CollectieUitwisseling : beheert
CollectieUitwisseling "*" --> "1" AndereBibliotheek : met
CollectieUitwisseling "*" --> "*" Uitleenitem : betreft

note right of Boekkeurder
  Boekkeurder gaat boeken en
  andere artikelen langs en:
  - Voert conditie inspecties uit
  - Keurt boeken af (methode)
  - Bestelt bij (methode)
end note

note right of ConditieInspectie
  Een boekkeurder voert een
  conditie inspectie uit op een
  exemplaar en bepaalt de conditie.
  Bevat inspectiedatum en opmerkingen.
end note

note right of Exemplaar
  In dit subdomein heeft exemplaar
  een status 'uitgeleend' (boolean).
  Geen relatie met klanten/reserveringen.
end note

note right of Conditie
  Conditie is dynamisch in dit
  subdomein - kan worden bijgewerkt
  door boekkeurder
end note

note right of CollectieUitwisseling
  Uitwisseling van collecties
  met andere bibliotheken
  voor diversiteit.
  
  Dit kan leiden tot een 3e subdomein
  "Boekdistributie": vrachtwagen voor
  honderden boeken over grote afstand
  (tussen steden), of fiets/kar voor
  kleine afstand (twee bibliotheken in
  één stad, maandelijks 20 boeken).
  Vragen: rijduur, aantal uitladers, etc.
  Dit diagram werken we NIET uit.
end note

note right of Uitleenitem
  aantalUitleningen helpt bij
  beslissingen over vervanging
  (populaire vs. weinig uitgeleende items)
end note
@enduml

Glossary - Subdomein Collectie onderhoud

Shared Kernel: In de praktijk zouden deze subdomeinen mogelijk verschillende bounded contexts worden in het oplossingsdomein. Concepten zoals Uitleenitem en Exemplaar komen in beide subdomeinen voor. Volgens Evans (2003) kun je hiervoor een Shared Kernel patroon gebruiken: een expliciet gedeeld model tussen bounded contexts. Dit moet zorgvuldig worden beheerd, omdat wijzigingen in de shared kernel beide bounded contexts beïnvloeden. Alternatief is om deze concepten te dupliceren per bounded context (Conformist of Separate Ways), maar dan moet je wel synchronisatie regelen.

Opdracht: Maak voor je eigen projectcasus een domein model en glossary. Begin met een initiële (eenvoudige) versie met alleen de belangrijkste concepten. Zorg dat het model klein blijft (past op één A4). Maak het model met Mermaid of PlantUML (via de PlantUML Online Server of de VS Code PlantUML Extension) en voeg een glossary tabel toe met definities van alle termen. Valideer je domein model met niet-technische stakeholders (bijvoorbeeld je opdrachtgever of product owner) om te controleren of je het probleem goed hebt begrepen.

6. Kwaliteitscriteria voor domein model

6.1 Doelgroep: (ook) niet-technische stakeholders

Het domein model is primair bedoeld voor communicatie met niet-technische stakeholders, zoals opdrachtgevers, product owners, en andere belanghebbenden, om te valideren of je het probleem goed hebt begrepen. Na validatie kun je het domein model gebruiken als basis voor je implementatie, maar je hoeft niet alle entiteiten uit het domein model te implementeren in je OO domain layer - kies alleen wat nodig is voor je MVP.

Belangrijk: Omdat het domein model bedoeld is voor niet-technische stakeholders, moet je in het domein model geen technische OO-concepten gebruiken zoals:

• Overerving (inheritance)
• Interfaces of abstracte classes
• Polymorfie
• Entities vs. Value Objects (DDD concepten)

Ook DDD-concepten zoals Entities en Value Objects horen niet in het domein model thuis. Deze concepten zeggen een opdrachtgever meestal niets en geven het gevoel dat "dit diagram niet voor mij is maar voor developers", waardoor ze er niet goed naar kijken.

In de oplossingsfase (bijvoorbeeld in je Software Guidebook of domain layer) kun je wel kijken naar het onderscheid tussen Entities en Value Objects uit DDD, en object-georiënteerde concepten zoals overerving, interfaces en polymorfie gebruiken. Maar dit hoort niet in het domein model zelf, omdat dat model bedoeld is om het probleem te begrijpen en te communiceren, niet om de oplossing te ontwerpen.

Let op: Als je toch OO-concepten zoals overerving, compositie of aggregatie in een diagram wilt gebruiken (bijvoorbeeld in een technisch diagram voor developers), voeg dan altijd een legenda en goed beschrijvende labels toe. Zoals Simon Brown aangeeft in zijn presentatie "The lost art of Software Design" (26 oktober 2022): zonder legenda en duidelijke labels zijn diagrammen moeilijk te begrijpen, zelfs voor technische stakeholders. Dit geldt echter niet voor het domein model zelf, dat bedoeld is voor niet-technische stakeholders.

6.2 Checklist

Gebruik onderstaande Checklist 1 om te controleren of je domein model en glossary voldoen aan de kwaliteitseisen. Druk op Ctrl+D om aanvullende details te tonen.

Checklist 1: Kwaliteitscriteria domein model

• DM-1: Maak het domein model begrijpelijk voor de opdrachtgever: Je gebruikt entiteitnamen die herkenbaar zijn voor de opdrachtgever en je gebruikt Ubiquitous Language (de taal die stakeholders in het domein gebruiken) consistent in het diagram, de glossary en de toelichting. Je gebruikt domeintermen zoals "Boeklener" in plaats van generieke termen zoals "Klant" of "Gebruiker". Je vermijdt OO "weasel words" zoals "UitleenInstantie" of "LeenCategorie" — je gebruikt liever concrete domeintermen zoals "Bibliotheek" of "Uitleenperiode".
• DM-2: Je richt het domein model niet al op een oplossing: Je domein model beschrijft het probleemdomein, niet al het oplossingsdomein. Het criterium is niet 'gaat ons (beoogde) systeem dit opslaan?'², maar 'zijn alle relevante entiteiten uit het probleemdomein aanwezig?'.
• DM-3: Je voegt een legenda toe aan het domein model: Als je relaties of pijlen gebruikt, voeg je een legenda toe die uitlegt wat de verschillende soorten relaties betekenen. Je gebruikt niet teveel verschillende soorten pijlen en je bewaart technische OO-concepten zoals overerving, interfaces voor latere uitwerking van de oplossing, zodat je nu op het probleem focust.

Opdracht: Bedenk zelf minimaal twee aanvullende kwaliteitscriteria voor een domein model die Checklist 1 niet geeft. Denk bijvoorbeeld aan aspecten zoals: validatie met stakeholders, onderhoudbaarheid, of andere aspecten die belangrijk zijn voor een goed domein model. Leg uit waarom deze criteria belangrijk zijn en hoe je ze zou kunnen controleren.

7. Verder lezen/verdiepen

Subdomeinen en Context Mapping

Als je het domein model opsplitst in subdomeinen (zie criterium DM-6), maak je meerdere domeinmodellen, elk met een eigen toelichting. Je voegt ook een algemene introductie toe waarin je de subdomeinen introduceert. Zorg dat je de subdomeinen een korte maar beschrijvende naam geeft, zoals 'Uitleensysteem' en 'Collectie beheer' uit het voorbeeld in sectie 5.

Als je echt richting 'Software Architect' niveau wilt stijgen, kun je ook nadenken over en verdiepen in de Context Mapping techniek uit DDD. Dit is het derde strategische pattern uit DDD naast de 'Ubiquitous Language' en 'Bounded Context' patterns. Context mapping gaat over welke relatie subdomeinen onderling hebben, wie is client (upstream) en wie is server (downstream), zijn er 'generic subdomains' (zoals authenticatie), of shared kernels. Zie voor meer informatie de video "The Ultimate Guide to Context Mapping in Domain Driven Design" (Master AWS with Yan, 27-11-2024).

Subdomein Overzicht vs. Context Map

Er is een belangrijk onderscheid tussen een Subdomein Overzicht (probleemdomein) en een Context Map (oplossingsdomein):

• Subdomein Overzicht: Toont de verschillende business-domeinen en hun onderlinge afhankelijkheden op conceptueel niveau. Dit is wat je maakt voordat je naar de oplossing kijkt. Het laat zien hoe de business is georganiseerd, welke domeinen informatie uitwisselen, en wat de kernactiviteiten zijn.
• Context Map: Toont hoe bounded contexts (applicaties/modules) op elkaar aansluiten, met technische patterns zoals Shared Kernel, Customer-Supplier, Conformist, Anti-Corruption Layer, etc. Dit is een oplossingsdomein-diagram.

Interessant is dat er vaak een natuurlijke mapping is tussen subdomeinen en bounded contexts — dit is het effect van Conway's Law: "Organizations design systems that mirror their own communication structure." De applicaties die een organisatie bouwt, volgen vaak de afdelingsstructuur. Een Subdomein Overzicht kan daarom een goede voorspeller zijn voor de latere architectuur.

Voorbeeld: Subdomein Overzicht Bibliotheek

Figuur 9 toont een voorbeeld van een Subdomein Overzicht voor de bibliotheek casus. Dit diagram toont de subdomeinen op business-niveau, met hun onderlinge afhankelijkheden en classificatie (core, supporting, generic).

Figuur 9: Subdomein Overzicht — business-niveau overzicht met core, supporting en generic subdomeinen.

@startuml
!theme plain
skinparam rectangle {
  roundCorner 10
}

title Subdomein Overzicht - Bibliotheeksysteem

' Core subdomeinen (primaire business)
rectangle "**Uitlenen**\n(Core)" as Uitlenen #LightGreen
rectangle "**Collectie Onderhoud**\n(Core)" as Collectie #LightGreen

' Supporting subdomeinen (ondersteunend)
rectangle "**Klantbeheer**\n(Supporting)" as Klant #LightBlue
rectangle "**Boekdistributie**\n(Supporting)" as Distributie #LightBlue

' Generic subdomeinen (generiek, evt. off-the-shelf)
rectangle "**Notificaties**\n(Generic)" as Notificatie #LightGray
rectangle "**Betalingen**\n(Generic)" as Betaling #LightGray

' Relaties tussen subdomeinen
Uitlenen --> Klant : heeft klantgegevens\nnodig
Uitlenen --> Collectie : checkt beschikbaarheid\nexemplaren
Uitlenen --> Notificatie : triggert\nherinneringen
Uitlenen --> Betaling : int boetes bij\nte laat inleveren

Collectie --> Distributie : vraagt aanvulling\nbij tekort
Distributie --> Collectie : levert nieuwe\nexemplaren

Klant --> Notificatie : ontvangt\nberichten
Klant --> Betaling : betaalt\nlidmaatschap

' Legenda
legend right
  |= Kleur |= Type |= Betekenis |
  | <#LightGreen> | Core | Kernactiviteit, unieke waarde |
  | <#LightBlue> | Supporting | Ondersteunend, kan uitbesteed |
  | <#LightGray> | Generic | Generiek, off-the-shelf mogelijk |
endlegend

@enduml

Toelichting bij het diagram:

• Core subdomeinen (groen): Dit zijn de kernactiviteiten die de bibliotheek uniek maken. Hier investeer je het meest in maatwerk.
• Supporting subdomeinen (blauw): Ondersteunende domeinen die nodig zijn maar niet de kern vormen. Ze zijn wel domeinspecifiek — een bibliotheek heeft andere klantgegevens nodig (lidmaatschappen, leenrechten, leeftijdscategorieën) dan bijvoorbeeld een webshop.
• Generic subdomeinen (grijs): Generieke functionaliteit die elk bedrijf nodig heeft, ongeacht het domein. Deze kun je vaak kopen als off-the-shelf oplossing (bijv. Twilio voor notificaties, Mollie voor betalingen).

Supporting vs. Generic — wat is het verschil?

Het onderscheid tussen Supporting en Generic is soms subtiel. De kernvraag is: "Is dit specifiek voor mijn domein, of heeft elk bedrijf dit nodig?"

Let op: De grens is niet altijd scherp. Je zou kunnen beargumenteren dat "Klantbeheer" ook generic is (elk bedrijf heeft klanten). Maar zodra je domeinspecifieke attributen toevoegt (zoals "maximaal aantal gelijktijdige uitleningen"), wordt het Supporting. De classificatie hangt af van hoeveel domeinlogica erin zit.

De pijlen tonen welk subdomein informatie nodig heeft van een ander subdomein. Dit is nog geen technische integratie — het toont de business-afhankelijkheden. In een latere Context Map zou je deze relaties vertalen naar concrete integration patterns.

Let op: Dit Subdomein Overzicht is een optioneel verdiepingsdiagram. Voor de meeste projecten in de minor is een enkel domein model voldoende. Maak dit overzicht alleen als je domein model te groot wordt en je het wilt opsplitsen (zie criterium DM-6).

Quiz

Test je kennis over domein modellen, DDD en Design Thinking met deze multiple choice quiz:

Bronnen

• Design Council. (z.d.). The Double Diamond. Design Council. Geraadpleegd op 6 januari 2026, van https://www.designcouncil.org.uk/our-resources/the-double-diamond/
• Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional. Geraadpleegd op 6 januari 2026, van https://www.domainlanguage.com/ddd/
• Fowler, M. (2003, 25 november). AnemicDomainModel. martinfowler.com. Geraadpleegd op 6 januari 2026, van https://martinfowler.com/bliki/AnemicDomainModel.html
• Gupta, N. (2019, 7 februari). Problem Space vs Solution Space. Medium. Geraadpleegd op 6 januari 2026, van https://medium.com/@nikhilgupta08/problem-space-vs-solution-space-f970d4ace5c
• Lambrych, J. (2024, 25 juni). Domain-Driven Design (DDD): Strategic Design Explained. Medium. Geraadpleegd op 6 januari 2026, van https://medium.com/@lambrych/domain-driven-design-ddd-strategic-design-explained-55e10b7ecc0f
• Larman, C. (2004). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd ed.). Prentice Hall. Geraadpleegd op 6 januari 2026, van https://www.craiglarman.com/wiki/index.php?title=Book_Applying_UML_and_Patterns
• Master AWS with Yan. (2024, 27 november). The Ultimate Guide to Context Mapping in Domain Driven Design [Video]. YouTube. Geraadpleegd op 6 januari 2026, van https://www.youtube.com/watch?v=6_pQRH9wYtU
• Wikipedia contributors. (2024). Subset. Wikipedia, The Free Encyclopedia. Geraadpleegd op 6 januari 2026, van https://en.wikipedia.org/wiki/Subset