This page is still in draft state. Please note that the content may be subject to change.
Domain-Driven Design of Large Software Systems (DDD) enables students to architect complex software systems from the ground up, using the DDD paradigm for designing loosely coupled software systems. The course focuses on the domain exploration, subdomain specification, and a prototypical implementation. Aspects of a technical architecture are not in focus in this course.
#rollenzuweisung
and click on
ddd.
Then you automatically get access to the channel(s) relevant for this module.
This module walks you through the design of a reasonably complex software system, from exploring its business domain to a running prototype built by several teams, using Domain-Driven Design.
As a experienced programmer, architect, or business analyst I can design a reasonably complex greenfield application for a multi-team development setup, using the domain-driven design paradigm,
by me ...
so that I can make sure that I have a sound, sustainable high-level architecture for my business domain.
| Phase | Period (by workshops) | What is produced | Team |
|---|---|---|---|
| Phase 1: Kickoff We agree on the goals, the structure and the grading of this module, and we form the specialist teams.
| 02.10.2026 | ||
| Phase 2: Domain exploration We explore the case study domain (a restaurant management system) together in a big-picture EventStorming, moderated by the exploration team, and document what the wall shows: the domain events, the business objects, and the first candidate boundaries.
| 16.10.2026 |
| Exploration Team |
| Phase 3: Strategic design We turn the EventStorming result into bounded contexts with the core domain chart, domain stories and the context map: which subdomains are core, which scenarios run through them, and where the boundaries run. At the end of this workshop day, the bounded context teams form.
| 23.10.2026 |
| Strategic Team |
| Phase 4: High-level architecture Each bounded context becomes a service in a microservice architecture on Kafka. We describe it with the C4 model at levels 1 and 2; the architecture team takes the technology decisions that go beyond a single service, in agreement with the supervisors; the tactical team hands out the starter platform, and the implementation starts.
| 06.11.2026 |
| Architecture Team |
| Phase 5: Tactical design and implementation The bounded context teams implement their contexts as services. They start right after the architecture workshop and work things out for themselves first; the two workshops of the tactical team then give them the tools to improve on what they have: the tactical building blocks, and a proper setup for working with an AI agent. Two status meetings follow.
| 27.11.2026 04.12.2026 18.12.2026 15.01.2027 |
| Tactical Team Bounded Context Team |
| Phase 6: Demo and reflection Each bounded context team demonstrates its service in the running system, reflects on the method, and hands over its architecture in a state that someone who was not in this course can work with.
| 05.02.2027 |
| Bounded Context Team |
This course follows the jigsaw approach to cooperative learning: you work in two teams at the same time, and the two are cut along different axes.
Every context team holds at least one member of every specialist team, and that is the point of the arrangement rather than a scheduling detail. A method is not learned from attending one workshop, and it cannot be coached into a team from outside it. Whoever prepared the Context Map workshop sits in your team at the moment you have to draw your own boundary.
How many bounded contexts we cut the case study into depends on how many of you there are, so we settle that at the end of phase 3, when the bounded context teams form.
Each team has a charter. It says what the team is there for (mission), what it does as soon as we leave the kickoff (first steps after the kickoff), what it does on its own workshop day, what it delivers, which role it keeps for the rest of the semester, and how the supervisors support it. All specialist teams start working right after the kickoff, not only when their phase comes up.
The chart shows roughly when each team is busy. You are in one specialist team and in one bounded context team, so your own load is your specialist team’s row plus the grey row.
The tactical team is staffed from those of you who already know the DDD building blocks from an earlier course. Expressing an architectural rule as an automated check means knowing the rule well enough to say precisely when it is violated, so this is the team where existing knowledge earns its place. The other three specialist teams are open, since the methods they own are new to nearly everyone.
Four quick questions, just for orientation. The actual assignment happens at the kickoff, based on the survey there.
There is a survey on Xoyondo where you can state your team preferences. (I would gladly have used an officially sanctioned university tool for this, but none of them lets you edit your choices after you have made them. So this is a compromise with a relatively privacy-friendly third-party tool, which I also use in other contexts.)
The tactical team is staffed from those of you who already know the DDD building blocks, so if that is you, please say so in the survey. We fill in the survey together during the kickoff on 02.10.2026 and evaluate it on the spot, so that all teams are formed when we leave the room: the exploration team has only two weeks until the EventStorming day. If you cannot attend the kickoff, or do not want to use the tool, send me your preferences by another channel (for example email) before the kickoff.
The case study will be a restaurant management system, as described in the case study description. The code repository for it will be https://git.archi-lab.io/students/ddd/ws26/restaurant-system.
The architectural style is given in this course rather than chosen by you: a set of microservices integrating over Apache Kafka, with one service per bounded context. The supervisors provide the infrastructure (Kafka and PostgreSQL in Docker) and helper libraries for the outbox pattern and for Kafka producers and consumers, so that your effort goes into the domain rather than into plumbing. Each service documents the events it publishes, its event API, in AsyncAPI. A service counts as done when all its tests run green, its guardrail pipeline runs green, and it has no open merge requests.
At the end of the semester you hand over an architecture, not only a running system. In the summer semester, the ARCEN module reviews and evolves architectures of this kind, largely with people who were not in this course. What you produce here is therefore a deliberate first cut, and making it reviewable by someone who was not in the room is part of the work rather than an afterthought.
Every criterion is scored on the same scale. 0 means not acceptable at all, 3 means the criterion was overachieved. The four descriptions per criterion are the anchors of that scale, not the only values that can be awarded: half and quarter steps between them are possible.
Criteria carry different weights, and the reachable maximum is three times the sum of the weights, shown with the table. A third of the maximum is enough to pass the course with a grade of 4,0. A grade of 1,0 is awarded from eleven twelfths of the maximum upwards, and the grades in between are interpolated.
Passing the course requires that your service builds on the shared platform and that its guardrail pipeline runs green. That row carries no weight and earns no points, but until it is green there is nothing to assess in the other criteria of that part.
Team points may be modified according to individual contribution, see below.
| Part | Grading Aspect | Weight | 0 Points | 1 Points | 2 Points | 3 Points |
|---|---|---|---|---|---|---|
| Specialist Role (graded per specialist team) | Preparation and moderation of the phase your specialist team owns Where a specialist team owns two dates, which is always the case for the tactical team and from eighteen participants also for the architecture team, both deliverables are assessed together under this criterion. The second is expected to be smaller in scope than the first. | 2 | The method was not researched beyond the material handed out, and the phase was run ad hoc. The other teams received no usable brief and had to work the method out for themselves. | The method was researched superficially. The workshop took place, but its preparation shows gaps, and the coaching that followed was reactive rather than offered. | The method was researched properly and the phase was prepared with an agenda, material and the misconception probes. The other teams were coached through it when they asked. | The method was researched beyond the course material, and the pack anticipates where the other teams will go wrong rather than only describing the steps. The coaching continued into the implementation, which is where a method is actually tested. |
| Bounded Context Specification (graded per bounded context team) | Specification of the DDD artefacts for your context | 4 | The specification does not reflect what the case study produced. The artefacts contradict the Event Storming board or the context map, and the aggregates are asserted rather than argued for. | The specification reproduces some of the case study results, but the connection between them is thin. Boundaries are stated without saying which language or which invariant makes them boundaries. | The specification follows the case study through. The context and its relationships are argued from the context map, the container is consistent with the C4 model, and each aggregate is justified by the invariant it protects. | As for 2, and the specification states where it is uncertain and what would change the decision. A reader can see which alternatives were considered and why this cut won. |
| Bounded Context Implementation (graded per bounded context team) | Platform readiness of your service A precondition, not a scored criterion. Until the pipeline runs, there is nothing to assess under the two criteria that follow. | 0 | - | - | - | The service builds on the shared platform and the guardrail pipeline runs green. |
| Implementation of your context as a service There has to be enough code to judge. A service that is little more than scaffolding cannot be assessed above 1 point. | 4 | The service does not run, or it runs without respecting the boundary it was specified to have. Domain logic sits wherever it was convenient, and the integration with other contexts is direct coupling rather than messages. | The service runs and covers part of its context. Layering and context boundaries are crossed where crossing them was quicker, and the message integration works only along the path that was demonstrated. | The service covers its context, keeps its boundary, and integrates over messages rather than by reaching into another context. The aggregates in the code are the ones in the specification. | As for 2, and the service behaves sensibly when its neighbours do not. Messages that arrive twice, out of order, or not at all are handled as a design concern rather than discovered during the demo. | |
| Working method with the agent and the architectural guardrails | 2 | The agent was used as an oracle. Generated code was accepted or discarded wholesale, guardrail failures were worked around by weakening the rule, and nothing in the repository records how the team works. | The agent was used with some care, but the conventions it was given stayed as they were handed over. A failing guardrail was more often silenced than understood. | The conventions, permissions and checks were treated as part of the work. The team extended them as the domain got clearer, and a failing check led to a design conversation rather than to an exception. | As for 2, and the team can show a case where it argued that the guardrail was wrong and changed the rule, or that the code was wrong and changed the code. The setup is demonstrably better at the end than it was when handed over. | |
| Reviewability of the submission by someone who was not there The test behind this criterion is whether a reviewer who was not present could work with this architecture. It is not hypothetical: the ARCEN module in the summer semester reviews the result, largely with people who were not in this course. | 2 | The submission is a repository and nothing else. A reader who was not in the course cannot tell what the context is, why it was cut this way, or how to run it. | The artefacts are present but scattered, and they assume the reader sat in the workshops. Decisions appear as results with no reasoning attached to them. | The submission is self-contained. The context map, the C4 model, the specification and the guardrail set are where a reader expects them, and each design decision is legible without asking the team. | As for 2, and the submission names its own weak points. A reviewer can start from what the team already knows is unresolved instead of having to find it first. | |
| Reflection (graded per bounded context team) | Reflection on the method | 1 | The presentation recounts what was done. It contains no judgement about the method itself. | The reflection names advantages and drawbacks of the method in general terms that would fit any project. | The reflection is tied to this case study. It says where the method paid for itself, where it cost more than it returned, and what the team would do differently. | As for 2, and it says under which conditions the team would not use this method at all, with a reason drawn from what happened during the semester. |
| Course Participation (graded individually) | Contribution to the course beyond your own team | 1 | Barely present in the course beyond the obligations of the own team. | Present in the work of the own team, but not visible in the exchange between teams. | A reliable presence in discussions and in the coaching across teams, both asking and answering. | Visibly carried parts of the course for others, by guiding, unblocking and helping teams other than the own one. |
| Sum | 16 | Maximum reachable points: 48 | ||||
The team criteria above are assessed as a team effort, and I assume that all members of a team contribute equally. If that is not the case, for instance if one member clearly takes part much less in the team’s work, I reserve the right to reduce that member’s share of the team result. The individual grade can then deviate from the team grade, and in extreme cases lead to a failing grade.
Nobody gets more than 100 % of the team result. If only some members of a team carry the work, the team can still earn a good result; those members get the full result, and the others a correspondingly smaller share of it. Make sure your individual contribution is recognisable, for example by pushing your own commits when you pair or mob program.
| Individual Contribution | < 30 % | 30 … 80 % | 80 … < 100 % | 100 % |
|---|---|---|---|---|
| Level of individual contribution to the team’s work | Hardly involved in the team’s work at all. Contributions are not visible and can only be guessed. | Only occasionally or superficially involved. Contributions are scarce but visible. | Contributed slightly below average. | Played an active role and contributed in line with the assessment of the team’s work. |
At the end of the course, we will have a retrospective session, where each team reflects on the DDD methodology as we have applied it in this course. Each team will present their view on the strengths and weaknesses of the method, and what they would do differently in a real-world project. This is part of the grading.
I do NOT expect a well-prepared / well-trained presentation. PPT slides are NOT required. Voice only, Miroboard stickies, or what else makes you feel comfortable, is totally sufficient. The retrospective is done per sub-team from the case study implemention, since you spent the last half of the course mainly within your subteam. Therefore, you can distribute the questions amongst yourself, but I would expect that each answer to a question reflects the opinions of the whole sub-team.
Please use the following guiding questions for your reflection.
Moderated by: the teacher. We discuss the goals, structure, organizational details, and grading for this module. In addition, you get an introduction to the preconditions for this course and pre-courses, where applicable. You can read about the content in this slideset.
Room: 0505 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions.
You can start with this module.
Moderated by: Exploration Team. We use the EventStorming method in a workshop, and reflect on the results. The goal is to explore our case study domain in a "typical" DDD way. This workshop will be prepared and moderated by a dedicated "EventStorming" subteam. I will coach and support the moderators.
Room: 0505 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions.
You have the "big picture" ingredients for the case study (events, subdomain boundaries). And you have an understanding how this method works, of its strengths and limitations.
Moderated by: Strategic Team. We evaluate the EventStorming results and derive bounded contexts (the blueprints for service boundaries) from them. We use the core domain chart, domain storytelling and the context map, prepared and facilitated by the strategic team. I will coach and support the moderators. Two or three of the domain stories become the scenarios the system has to run end to end at the demo. At the end of the day, we form the bounded context teams.
Room: 0505 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions.
You have an detailed understanding of our domain, and how to derive it from the EventStorming results. (Agenda will be further detailed by the strategic team.)
Moderated by: Architecture Team. Based on the bounded contexts, we will now create a high-level C4 model. You can read about the content in this slideset.
You have a technical model of a microservice architecture for our domain. And you understand how aggregates are a key to design service components, and how to create a high-level C4 model from the bounded contexts and their aggregates.
Moderated by: Tactical Team. Aggregates, entities, value objects and repositories, taught with exercises and applied to the models your teams have started in the meantime. Where a model breaks a rule, we look at why, and what a better cut of the aggregate would be.
Your team knows which of its aggregates to rework, and why.
Moderated by: Tactical Team. Conventions, permissions and architectural guardrails for working with an AI agent in a team: the shared setup of the tactical team, checks that encode the context boundaries and the aggregate rules, and what a human reviews before a merge. Applied to your own repository.
Your service builds on the shared setup, and its guardrail pipeline runs.
Moderated by: the teacher. Where do the teams stand, and what blocks them? The bounded context teams show how far the demo scenarios already run end to end through their services. Half a day, on site or via Zoom, depending on whether a guest speaker joins. Details follow.
Moderated by: the teacher. Second status meeting: again the bounded context teams show how far the demo scenarios run end to end, and we prepare the demo and the handover. Half a day, on site or via Zoom. Details follow.
Moderated by: the teacher. Demos of the running system, and the retrospective of each bounded context team along the guiding questions below. No slides required.
You have shown what your service does, and you have a judgement on the DDD journey.