Quiz User Story Mapping, Application Services & Hexagonal Architecture

Quiz 1 — INVEST principes (Restaurant casus)

Bekijk de onderstaande User Story Map voor het Restaurant bestelsysteem. De map bevat een aantal fouten. Beantwoord de vragen.

USM bronbestand (textusm formaat)

# labels: ACTIVITEIT, GEBRUIKERSDOEL, USER STORY, SPRINT 1, SPRINT 2, SPRINT 3, BACKLOG
# release1: Sprint 1 - Basics; Bestellen en betalen
# release2: Sprint 2 - Social; Reviews, Tikkie
# release3: Sprint 3 - Reviews geven
# release4: Backlog (rest)
Menukaart bekijken
    Gast vraagt menu op
        US-01 Gast bekijkt menukaart
        US-02 Gast filtert op restricties
                US-03 Gast ziet beoordelingen
                    US-16 Gast geeft beoordeling
                US-04 Gast beheert menu
    Bestelling plaatsen
        US-05 Gast ziet ingrediënten
Bestelling plaatsen
    Gast kiest gerecht
        US-06 Gast voegt gerecht toe
        US-07 Gast past bestelling aan
    Gast bevestigt bestelling
        US-08 Gast bevestigt bestelling
        US-09 Gast ontvangt bevestigingsmail
Rekening betalen
    Gast vraagt rekening op
        US-10 Gast ziet rekening
        US-15 Gast betaalt rekening
    Betalen
        US-11 Gast betaalt met pin
        US-12 Gast betaalt met iDEAL
            US-13 Gast splitst rekening
                US-14 Medewerker ziet mislukte betalingen

Backlog overzicht:

US-X Code	Volledige user story
US-01	Als gast wil ik de menukaart bekijken zodat ik iets kan kiezen
US-02	Als gast wil ik de menukaart filteren op voedingsrestricties zodat ik geschikte gerechten zie
US-03	Als gast wil ik beoordelingen zien van een gerecht zodat ik weet wat anderen vonden
US-04	Als gast wil ik een volledig beheersysteem voor de menukaart waarmee ik gerechten kan toevoegen, bewerken, verwijderen, prijzen aanpassen, allergenen beheren, foto's uploaden en dagmenu's instellen zodat de kaart altijd up-to-date is
US-05	Als gast wil ik de ingrediënten van een gerecht zien zodat ik het kan bekijken
US-06	Als gast wil ik een gerecht toevoegen aan mijn bestelling zodat ik het geserveerd krijg
US-07	Als gast wil ik mijn winkelmandje kunnen aanpassen zodat ik fouten kan corrigeren
US-08	Als gast wil ik mijn bestelling bevestigen zodat de keuken aan de slag gaat
US-09	Als gast wil ik een bevestigingsmail ontvangen zodat ik bewijs heb van mijn bestelling
US-10	Als gast wil ik de rekening kunnen zien zodat ik weet wat ik verschuldigd ben
US-11	Als gast wil ik kunnen betalen met pin zodat ik mijn schuld vereffen
US-12	Als gast wil ik kunnen betalen met iDEAL zodat ik mijn schuld vereffen
US-13	Als gast wil ik de rekening kunnen splitsen zodat ik alleen mijn eigen gerechten betaal
US-14	Als restaurantmedewerker wil ik zien welke betalingspogingen (pin of iDEAL) zijn mislukt zodat ik een gast proactief kan helpen
US-15	Als gast wil ik betalen

Kwaliteitscriteria voor een User Story Map

Een goede USM voldoet aan vier criteria:

De USM heeft de goede structuur — backbone van activiteiten (1e niveau) en gebruikersdoelen (2e niveau), met user stories (3e niveau) eronder en horizontale releases.
De USM heeft de goede vulling — user stories zijn geprioriteerd, meest waardevolle bovenaan; stories in sprint 1 hebben acceptatiecriteria.
De user stories zijn goed qua vorm — elke story volgt 'Als [rol] wil ik [doel] zodat [reden]'; de rol is herkenbaar en het 'zodat'-deel beschrijft bedrijfswaarde.
De user stories zijn inhoudelijk goed (INVEST) — Independent, Negotiable, Valuable, Estimable, Small, Testable.

Vragen over de INVEST-principes en kwaliteitscriteria voor user stories aan de hand van de restaurant casus.

Deze quiz helpt je toetsen of je de bron echt hebt bekeken/gelezen en begrepen. Zo niet: bekijk/lees de bron opnieuw. Gebruik deze quiz niet als 'gaming' voor de toets; de toetsvragen zijn inhoudelijk anders.

1.1. In de User Story Map hierboven staan de user stories in verkorte vorm (bijv. 'US-06 Gast voegt gerecht toe'). Is het toegestaan om user stories verkort op te schrijven in een USM?

Nee, de volledige 'Als [rol] wil ik [doel] zodat [reden]' zin moet altijd in de User Story map staan, anders is deze onvolledigJa, als de volledige zin te lang is, zolang maar ergens een goed 'zodat'-deel is, typisch in de backlog/issue systeemJa, verkorting is zelfs verplicht!Nee, verkorte stories zijn nooit testbaar (INVEST-T) en dus altijd ongeschikt voor een USM

1.2. In de map staat US-04 'Gast beheert menu' (zie backlog overzicht voor de volledige tekst). Welk INVEST-principe wordt als eerste geschonden?

I — Independent: de story heeft te veel afhankelijkheden van andere systemenS — Small: de story pakt zoveel functionaliteit in één keer op dat ze nooit in één sprint past naast andere storiesV — Valuable: de story levert geen herkenbare waarde op voor de eindgebruikerN — Negotiable: de story is te gedetailleerd gespecificeerd en laat geen ruimte voor discussie

1.3. US-06 en US-08 lijken afhankelijk van elkaar. Een collega stelt voor ze samen te voegen. Wat is het bezwaar, en wat is een betere aanpak?

Samenvoegen is prima; zo hoef je maar één keer te testen en bespaar je tijd in de sprintBezwaar: dit schendt V (Valuable). Beter: de afhankelijkheid accepteren en apart documenterenBezwaar: samenvoegen schendt S (Small). Beter: stories herformuleren zodat ze elk los waardevol en testbaar zijnBezwaar: dit schendt I (Independent). Beter: één van de twee stories schrappen uit de backlog

1.4. Bekijk US-03 (zie backlog overzicht). Hoe valideer je als developer dat het 'zodat'-deel goed is?

Door in het 'zodat'-deel goed het 'hoe' uit te leggen zodat je een duidelijke implementatiespecificatie hebtDoor het 'zodat'-deel taalkundig goed aan te laten sluiten bij het 'wat'- en 'hoe'-deelDoor te checken dat de restauranthouder of een gast de 'zodat...' herkent als inderdaad waardevolDoor het 'zodat'-deel taalkundig goed aan te laten sluiten bij het 'wie'- en 'wat'-deel

1.5. US-09 gaat over een bevestigingsmail (zie backlog overzicht). Welke opmerking past het beste bij deze story vanuit het perspectief van core/supporting/generic domain?

Core domain: e-mail sturen is uniek voor dit restaurant en onderscheidt ons van de concurrent; moet hoog geprioriteerd wordenGeneric domain: e-mail versturen is voor elk bedrijf hetzelfde; gebruik een bestaande dienst (bijv. SendGrid) en geef core-domain stories hogere prioriteit in de USMSupporting domain: e-mail ondersteunt het kernproces en is specifiek genoeg voor dit restaurant dat je het altijd zelf bouwt als eerste featureHet domeintype doet er niet toe voor de volgorde in de USM; alle stories krijgen dezelfde prioriteitsmethodiek ongeacht of het core, supporting of generic domain is

1.6. US-15 in de map luidt (zie backlog overzicht): 'Als gast wil ik betalen'. Welk kwaliteitscriterium van de USM is hier in het geding?

De USM heeft de goede structuur — de story staat op het verkeerde niveau in de mapDe USM heeft de goede vulling — de story ontbreekt in de release-indelingDe user stories zijn goed qua vorm — het zodat-deel (de reden/waarde) ontbreektDe user stories zijn inhoudelijk goed (INVEST) — de story schendt E (Estimable)

Quiz 2 — Core domain vs. supporting/generic domain (Restaurant casus)

Vragen over de keuze tussen eigen software schrijven of bestaande oplossingen gebruiken.

In deze course hoef je alleen het onderscheid te kennen tussen core domain en supporting/generic domain als 2 categorieën. Een verder onderscheid tussen supporting en generic domain bestaat er in de literatuur wel, zie uitklapbalk, maar is niet relevant voor de toets of deze quiz.

ℹ️ Verschil supporting vs. generic domain (verdieping, niet voor toets)

Een supporting domain ondersteunt het core domain maar creëert alleen indirect meerwaarde. Denk aan voorraadbeheer in een restaurant: er wordt geen maaltijd bereid, maar zonder peterselie op het bord is de klant ontevreden. Een generic domain is bovendien generiek — het is bruikbaar voor heel veel andere bedrijven en problemen, niet specifiek voor dit bedrijf.

Een supporting domain kan tegelijk generic zijn (bijv. e-mail versturen), maar dat hoeft niet: een heel specifiek voorraadbeheerssysteem voor dit restaurant is supporting maar niet generic. Als zo'n specifiek supporting domain groot genoeg wordt, kun je het als apart bedrijfsonderdeel zien dat het als eigen core domain beschouwt.

Voor developers geldt: voor het core domain schrijf je custom software die jouw Unique Selling Point ondersteunt. Voor supporting/generic domains gebruik je bestaande libraries, frameworks of cloud-diensten en koppel je die aan je core domain software.

Dit onderscheid wordt ook gebruikt in het DDD Context Mapping pattern (een andere strategic pattern, naast Ubiquitous Language en Bounded Context — zie de uitklap in Les 1-3). En ook in de techniek Wardley Mapping, die visualiseert hoe generiek of uniek onderdelen van je systeem zijn. Beide behandelen en toetsen we verder niet in DomExp.

2.1. Het restaurantbestelsysteem heeft twee features: (1) het bijhouden van bestellingen per tafel en (2) het verwerken van pinbetalingen via Mollie. Wat is het verschil voor jou als developer?

Feature 1 en 2 vragen allebei een domain-driven aanpak; het enige verschil is de architectuurvormFeature 1 ontwikkel je met eigen (custom) software; feature 2 realiseer je via een bestaande library of payment-providerFeature 2 is het core domain en vraagt custom software; feature 1 is generic en gebruik je een framework voorVoor beide features gebruik je een CRUD-aanpak, maar feature 1 heeft een rijker domeinmodel

2.2. Het restaurant wil e-mails sturen naar gasten met hun bestellingsbevestiging. Tot welk domein behoort dit, en wat betekent dat voor de implementatie?

Core domain — e-mail versturen is uniek voor dit restaurant en moet volledig zelf gebouwd wordenSupporting domain (specifiek voor dit restaurant) — e-mail ondersteunt het kernproces, dus moet je het zelf bouwenGeneric domain — e-mail versturen is voor elk bedrijf hetzelfde; gebruik een bestaande dienst (bijv. SendGrid) en koppel die aan je core softwareDit onderscheid maakt voor de implementatie niets uit; e-mail is altijd een simpele REST-call

2.3. Het restaurant wil een systeem voor voorraadbeheer: bijhouden wanneer ingrediënten verlopen en tijdig weggooien. Dit ondersteunt de kernactiviteit (maaltijden bereiden) maar de core business draait nu ook zonder zo'n systeem?

Core domain — voorraadbeheer raakt direct de kwaliteit van de maaltijdenSupporting domain — het ondersteunt het core domain indirect, maar is specifiek genoeg voor dit restaurant dat je het zelf bouwt of een specifieke oplossing kiestGeneric domain — voorraadbeheer is voor elk bedrijf hetzelfdeDit is geen software-domein; voorraadbeheer hoort bij operations, niet bij softwareontwikkeling

2.4. Wat is de belangrijkste reden om voor het core domain eigen (custom) software te schrijven in plaats van een bestaand framework of cloud-dienst te gebruiken?

Eigen software is altijd goedkoper dan licenties voor cloud-dienstenHet core domain bevat de unieke bedrijfslogica die de organisatie onderscheidt van concurrenten — dat is juist het Unique Selling Point dat je wilt investeren in custom softwareFrameworks en cloud-diensten zijn te traag voor core-domein-functionaliteitSecurity-eisen verplichten eigen implementaties voor core-domein-functionaliteit

Quiz 3 — Lagen en relaties (Restaurant casus)

Vragen over toegestane en niet-toegestane relaties tussen lagen. Gebruik het onderstaande klassendiagram als referentie bij de vragen.

b775eab8446eb2b8798afd3e1d1bc37c

PlantUML broncode voor "Klassendiagram Restaurant lagen"

@startuml
package "Controller" {
    class BestellingController {}
}

package "Service" {
    class BestellingService {}
    class MenuService {}
}

package "Repository" {
    interface BestellingRepository {}
    interface MenuRepository {}
}

package "Domain" {
    rectangle "Bestelling Aggregate" {
        class Bestelling <<Aggregate Root>> {
            -id: Integer
            -tafelId: Integer
        }
        class BestellingStatus <<Value Object>> {
            CONCEPT
            GEPLAATST
            BETAALD
        }
    }
    rectangle "Gerecht Aggregate" {
        class Gerecht <<Aggregate Root>> {
            -id: Integer
            -naam: String
        }
    }
}

Bestelling --> BestellingStatus
@enduml

3.1. Is de volgende associatie toegestaan: BestellingController --> BestellingService?

Altijd toegestaan — dit is de normale laagvolgorde van buiten naar binnenNiet toegestaan — controllers mogen geen services aanroepenValt over te discussiëren — soms is een directe databaseverbinding in de Controller aanmaken beterNiet toegestaan — een controller moet altijd via een use case interface werken

3.2. Is de volgende dependency toegestaan: Gerecht ..> MenuRepository?

Altijd toegestaan — domeinobjecten mogen repositories aanroepen voor gerelateerde dataNiet toegestaan — het domein mag niets weten van repositoriesValt over te discussiëren — alleen als het een interface isAltijd toegestaan — dit is de Dependency Inversion principle

3.3. Is de volgende dependency toegestaan: BestellingRepository ..> Gerecht (repository geeft Gerecht terug)?

Altijd toegestaan — een repository mag altijd domeinobjecten teruggevenNiet toegestaan — een repository mag alleen objecten teruggeven van het eigen aggregateValt over te discussiëren — zolang het een read-only operatie is of je een Join-query gebruiktAltijd toegestaan — dit is een return-type dependency, geen associatie, je kunt ook customDTO gebruiken

3.4. Is de volgende dependency toegestaan: BestellingService ..> Bestelling (service gebruikt eigen domeinobject)?

Niet toegestaan — een service mag geen domeinobjecten direct gebruiken, alleen DTO'sValt over te discussiëren — alleen als Bestelling geen businesslogica bevatAltijd toegestaan — een service mag domeinobjecten van het eigen aggregate gebruikenNiet toegestaan — de service moet altijd via een repository met domeinobjecten werken

Quiz 4 — Hexagonal Architecture (Restaurant casus)

Vragen over het plaatsen van klassen in de lagen van de hexagonal architecture. Gebruik het onderstaande diagram als referentie.

NB: In sommige bronnen (zoals Ted Young) heten poorten driving ports (inbound) en driven ports (outbound). In deze quiz gebruiken we de verzamelterm ports voor beide, en adapters voor de implementaties aan de buitenkant.

Hexagonal Architecture diagram

4.1. In welke laag van de hexagonal architecture hoort de class BestellingController thuis?

Adapters (buiten de hexagon) — het is een inkomende adapter die HTTP-verzoeken vertaalt naar use case-aanroepenDomain / Application core (binnenste hexagon) — het is de centrale besturingsklassePorts (binnenste ring) — het definieert de use case-interfacesAdapters (buiten de hexagon) — het is een uitgaande adapter voor externe communicatie

4.2. In welke laag hoort interface PlaatsBestellingUseCase thuis?

Adapters (buiten de hexagon) — het is een externe adapterPorts (binnenste ring) — het definieert wat het systeem kan doen vanuit de buitenwereldDomain / Application core (binnenste hexagon) — het is een domeinserviceAdapters (buiten de hexagon) — het implementeert een uitgaande koppeling

4.3. In welke laag hoort interface BestellingRepository thuis?

Adapters (buiten de hexagon) — het is een concrete database-implementatieDomain / Application core (binnenste hexagon) — het is een domeininterfacePorts (binnenste ring) — het definieert een poort naar de databaseAdapters (buiten de hexagon) — het ontvangt HTTP-verzoeken

4.4. In welke laag hoort class BestellingJDBCRepository thuis?

Ports (binnenste ring) — het definieert de repository-interfaceDomain / Application core (binnenste hexagon) — het slaat domeinobjecten opPorts (binnenste ring) — het beschrijft alleen de contractenAdapters (buiten de hexagon) — het is een adapter die de repository-poort implementeert via JDBC

4.5. In welke laag hoort class MollieBetalingService thuis?

Adapters (buiten de hexagon) — het ontvangt gebruikersinputPorts (binnenste ring) — het definieert de betaalinterfaceAdapters (buiten de hexagon) — het is een adapter die de BetaalService-poort implementeert via de Mollie APIDomain / Application core (binnenste hexagon) — het bevat betaallogica

Quiz 1 — INVEST principes (Restaurant casus)​