Up to here, you have built the workspace and enforced boundaries. What remained open is the question where the boundaries should run. A rule that protects a wrongly cut domain only makes the mistake more expensive. This lesson clarifies how to find cuts: with the strategic side of domain-driven design (DDD). The result is a context map of the Kladde as a file in the repository and a decision about it. The craft behind it (domain model, events, event storming) is taught by K4 in module 4.2; the lesson links to it and does not repeat it.

State of the checks. Read on the day of writing, in the text of the pages: Microsoft Learn "Use Domain Analysis to Model Microservices" and the entry page "Tackling Business Complexity in a Microservice with DDD and CQRS Patterns" (it is short and points to books), and also the article "All about DDD for Angular & Frontend Architectures" by angulararchitects.io. Run (Node 24.22.3, TypeScript 6.0.3): the small example kontexte.ts below, with node kontexte.ts (exit 0, output below) and tsc --noEmit --strict (exit 0). The context map as a Mermaid diagram was not rendered; the files docs/kontexte.md and the ADR are text and not run. The Kladde's contexts follow the plan of this course (contacts, appointments with the booking, tenders). K4 cuts six contexts (additionally sales, quotes, tenants); where K4 names things differently, K4 4.2.4 applies for the names on the API side, check there.

Why by domain logic

An Angular project likes to grow in folders such as components, services and models. That feels tidy and cuts across everything a person does in the office: whoever has to change "appointments" changes in three folders, and every change touches those of the others. The article from angulararchitects.io (read in the text) demands that a large front end be broken into smaller parts, and along the business functions rather than the technical layers; DDD, above all its strategic part, helps to find and check such cuts. The Learn page says the same for services: design by capabilities of the business, not by horizontal layers such as data access, with loose coupling and high cohesion.

What you get from it is tangible: a change usually concerns one slice, a team can own it, and the lint run from 0102 can enforce the boundary.