+49 2261 8196 6367
Discord Server
Prof. Bente Personal Zoom
Steinmüllerallee 4
51643 Gummersbach
Gebäude LC4
Raum 1708 (Wegbeschreibung)
Sprechstunde nach Vereinbarung
Terminanfrage: calendly.com Wenn Sie dieses Tool nicht nutzen wollen, schicken Sie eine Mail und ich weise Ihnen einen Termin zu.

Domain-Driven Design of Large Software Systems (DDD), WS21

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. DDD is a sequel to Fachspezifischer Architekturentwurf (FAE) in Master Computer Science (Software Engineering) study program, which is the predecessor of the Master of Digital Sciences. Both DDD and FAE will be taught jointly, until the Master Computer Science will expire.

Study Program and Module Description
Master Digital Sciences (specialization Software Architecture) (see also module description in the study program web site)
Begin/End and Scheduling
01.10.2021 - 28.01.2022. Organized as ca. 8 full-day workshops (Fridays 10:00 - 17:00), specific dates and agenda see below.
The module usually takes place in a purely online format.
Video conference link: https://th-koeln.zoom.us/j/88910722611?pwd=cXd0RzZMTzBrR0xZRU9hRnp5MVdQQT09 (only in exceptional cases and if explicitly communicated in advance for the day)
ILIAS/ILU Course for the Module
Registration for the Module
Please join this ILIAS/ILU course. Deadline is 12.09.2021. Please remember that you must additionally register for the exam via PSSO. The registration deadlines for this can be found on the F10 information pages of the TH Köln.
Maximum / Minimum Number of Participants
The maximum number of participants is 15. If there are less than 3 participants, the course cannot take place.

Learning Outcome

This module attempts to walk you through the design process of a relatively complex software system. This means creating a "fachspezifischen Architekturentwurf" (as the German name for module goes), meaning a domain-specific design for the problem. Modern software architecture means that you are close to coding. This means that we will have a case study at the center of the module. See below.

As a experienced programmer or architect I can design and implement a reasonably complex greenfield application in a multi-team approach, using the domain-driven design paradigm,

by me ...

  • exploring the domain and defining appropriate bounded contexts for the teams,
  • picking the suitable architectural style, according to the goals of for my software,
  • understanding the organisational preconditions wrt. DevOps,
  • defining service boundaries,
  • defining and implementing REST APIs in a suitable style,
  • defining and implementing events, using the appropriate architecture patterns,
  • roadmapping the UI architecture, and,
  • reflecting my architecture and development process,

so that I can make sure that the prototype that is jointly created during the course is sound and sustainable wrt. architecture and coding style.


This module will be part of The Microservice Dungeon project, which it will use as case study. The DDD / FAE members will act as “Dungeon Architects”, i.e. they will specifiy the APIs (with the teams), and discuss and document architecture decisions. This includes the following activities (plan status begin of October):

Phase Main Deliverable Activity
Specification & Planning
(29.9. - 8.10.)
- Detail level EventStorming - Understanding main DDD concepts
- Participation in EventStorming
- Focus on Detail Level as input for API design
Implementation & Integration Test
(5 Sprints of 2 weeks, from 11.10. - 17.12.)
- APIs
- Architecture Decisions
- Understanding API concepts (sync / async)
- Driving & documenting API design
- Documenting models and team architecture decisions
Player Implementation, Codefights, Presentation
(03.01. - 28.01.)
- Consistent documentation
- Working services
- Reflection on the project
- Code Review & Reflection
- Finalizing decision log
- Coordination of issues in the monitored service(s)
- Writing personal reflection (or alternative options, see below
- Preparing & holding presentation

DDD/FAE Role Decription

Each of you is responsible for one IP team (i.e. for one service). You will usually work in pairs. You have a double role: you are 1) product owner (PO) and 2) architect for your implementation team.

As a PO, you are the first contact for your team regarding “what features should the service have”. You need to prioritize tasks. If your team asks you what to do next, you need to have an answer. (If you don’t know yourself, go and discuss with your peer, or with the project supervisors). The backlog creation (e.g. as Github tasks) can be done by the team, but you need to supervise and check / enhance / correct it.

As an architect, you are responsible for all decisions concerning the service. This means that you specify and document:

  • API specification (REST, Events)
  • Feature completeness (check with gameplay team, if in doubt)
  • Architecture decisions

“Internal” decisions about the implementation can (and should) be made and documented by the team on its own. Any decisions concern interaction with other teams are your responsibility. You need at least to be informed and involved. This means you need to attend the following events:

  • MUST is participation in your IP team’s sprint review & planning
  • You need to follow their development in the meantime
  • You will report on the IP team status in the DDD / FAE workshops
  • There you will present recent decisions and the API status

Discussions and Information Sharing via Discord

Discord has been proven as a very effective platform for information sharing, discussions, and consultations. Therefore, Please join the ArchiLab Discord Server: https://discord.gg/YYNYb5whU8. Please choose “FAE” and “IP” as a role. Then you see the channels for this module (DDD/FAE specific) and (with IP) for the whole overarching project. Those students who don’t want to use Discord can of course contact me through other channels.


All Github repos will be created under a dedicated Github organization. The teams create their own repos there.

For documenting architecture decision, a Decision Log Tool is to be used. It is a Github Pages applications, bound to the repo https://github.com/The-Microservice-Dungeon/decisionlog.

Potential Collisions with ID and PADT

DDD / FAE is allocated on Fridays in the study planner tool “HOPS”. There is a potential collision with two other modules also placed on Fridays:

  • Interaction Design (ID) by Prof. Dr. Hartmann
  • Psychological aspects of digital transformation (PADT) by Prof. Dr. Dr. Palmer

  • The good news is that collisions with ID can be avoided completely, as ID and DDD/FAE will alternate on Fridays.
  • Collisions with PADT can be avoided mostly, as PADT will have a major block part. For more information,
  • please see the respective information pages.


  Date Time Location Content
1 Wed 29.09. 12:00 - 14:00 online Kickoff meeting (Orga, questions)
2 Fri 01.10. 10:00 - 17:00 CoCo S22 EventStorming - Big Picture
3 Mon 04.10. 10:00 - 17:00 CoCo S22 EventStorming - Details
4 Tue 05.10. 10:00 - 17:00 CoCo S22 EventStorming - Details
5 Fri 8.10. 10:00 - 14:00 online Planning
6 Fri 22.10. 10:00 - 16:00 online Sprint 1 (building infrastructure)
7 Fri 05.11. 10:00 - 16:00 online Sprint 2 (building infrastructure)
8 Fri 19.11. 10:00 - 16:00 online Sprint 3 (building infrastructure)
9 Fri 03.12. 10:00 - 16:00 online Sprint 4 (building infrastructure)
10 Fri 17.12. 10:00 - 16:00 online Sprint 5 (integration testing)
11 Mon 03.01. 10:00 - 11:00 online Organisational meeting
12 Fri 14.01. 10:00 - 12:00 online Codefight 1
13 Fri 21.01. 10:00 - 13:00 online Codefight - Testing
14 Thu 27.01. 10:00 - 16:00 online Codefight 2
15 Fri 28.01. 10:00 - 16:00 online Final presentation


The grade in this course consists of three parts.

60%: Quality of APIs, API documentation, and architecture decision log entries

This part of your grade is decided by a decision, documentation, and code review of those areas you have been responsible for, including an assessment of your role in the architectural and implementation process.

  • How well have you filled the PO / architect role?
  • How proactive have you been in the discussions, and in technical leadership for your teams?
  • What quality have the documents that you have created?

You don’t have to submit anything here. I will just review your contribution until 28.01.2022.

30%: Reflection (or alternative achievement)

Option 1: Reflection paper on the project and the quality of the created software

Please write a reflection paper (10 pages) on the project. In the following table, you see possible aspects (in German):

Thema Mögliche Aspekte
API-Qualität und API-First - Wie gut wurde das Prinzip eingehalten?
- War das sinnvoll für unser Projekt?
- Was waren Vorteile? Was hätte man besser machen können?
- Wie sähe hier eine effektive Governance aus?
- Wie gut ist die Qualität der REST-Endpoints?
- Wie gut ist die Qualität der Event-APIs?
Autorisierung und Fog of War - Wie gut hat die “Autorisierungs-Lösung” funktioniert (Verzicht auf Tools wie Keycloak, Nutzung von Netzwerken und Bearer-Token, Antwort per Transaction ID), um einen “Fog of War” aufrecht zu erhalten?
- Welche Lösung sollte man zukünftig verwenden?
Decision Log - War es für das Projekt sinnvoll, ein Decision Log zu führen?
- Was waren Vorteile? Was hätte man besser machen können?
- Wie sähe hier eine effektive Governance aus?
Kommunikation im Projekt - Wie bewerten Sie die Kommunikation im Projekt?
- Was lief gut? Was hätte man besser machen können?
Kommunikation unter den Services (sync / async) - Wie bewerten Sie die Kommunikations-Pattern (sync/async), insbesondere bei Commands
- Vielleicht spielen Sie einmal einen konkreten Ablauf-Chain (z.B. Game => Trading => Robot) durch, wie das mit asynchroner Kommando-Weitergabe aussehen würde
Service Schnitt (als ganzes) - Wie sinnvoll ist der im Projekt gewählte Service-Schnitt?
- Was würden Sie wieder genauso, was anders machen ?
Service Schnitt (Sicht des eigenen Services) - Wie bewerten Sie die Qualität des von Ihnen betreuten Service?
- Wo ist der Code gut, wo sollte man nachbessern?
Player Erstellung - Welche Herausforderungen gab es bei der Player-Erstellung?
- Wie bewerten Sie die Qualität der erstellten Player im Vergleich?
Command Struktur - Wie sinnvoll ist die Commandstruktur?
- Was ist gut? Was hätte man besser machen können?
DevOps - Wie bewerten Sie den DevOps-Teil des Projekts?
- Was lief gut? Was hätte man besser machen können?
Gameplay / Spielidee - Wie bewerten Sie die Spielidee und das Gameplay?
- Was lief gut? Was hätte man besser machen können?
Microservice Dungeon 2.0 - Wie bewerten Sie die Veranstaltung unter didaktischen Gesichtspunkten? Wo wurden die Lernziele erreicht, wo eher nicht?
- Wenn man die Veranstaltung wiederholt, was sollte man beibehalten? Was ändern?
Wildcard - Benennen Sie einen Aspekt, oder in der obigen Liste nicht genannt wurde, und untersuchen Sie ihn
  • Your paper needs to cover at least three of these aspects (per person), but you can cover more, if you want
  • You can write alone or in a team; it’s 10 pages per person, so 20 pages for 2-person-team, etc. Even in a team, you still need to contribute to at least 3 aspects.
  • Submission date is 18. February 2022.

Option 2: Implement your own player

If you implement your own player, the player code is reviewed. Max. achievement are 100 points (+ 50 Bonus). 40 points = 4.0, 90 points = 1.0 in this part (regular and bonus points are just added and treated the same).

  Max. Points Criteria Max. Bonus Bonus Criteria
Player strategy and implementation 30 - Player is able to fight 20 - original control or strategy
- degree of “sophistication”
Code quality / tactical DDD 30 - Clean Code rules kept- Entities and value objects appropriate
- Business logic is in domain layer (not in services)
- Domain Primitives exist, where it makes sense
- Aggregates well-formed
- Compact domain model documentation
- Application services well defined
- Domain und application layer cleanly separated in package structure
- -
API for controlling player 10 - If there are REST APIs for control: fit to aggregates, and according to REST standards
- Controllers in line with DDD (no business logic, call of application services)
10 - clients or other nice ways of visualization
Inter-Service-Kommunikation 10 - Synchronous Player commands to Game service implemented
- Answer events processed
10 - Events on actions of other players processed
Tests 10 - Unit tests cover main part of functionality 10 - very high test coverage
- originel tests and mocking
DevOps 10 - Build pipeline defined for player
- Player can participate in Codefight
- -
Sum 100   50  
  • You need to adhere to the general rules for players (need to be a repo in the Dungeon organization, etc.)
  • Submission date is 27.01.2022 (Codefight 2).
  • Your player’s success in the codefight is not relevant for grading! This is only about fun and winning.

Option 3: Contribute to service completion

The contribution to service completion (if the Informatikprojekt team would not be able to finish the job on their own) will also be graded according a code review. I will look at the commits, and apply a similar points scheme as for the own player implementation (see above).

Submission date is 27.01.2022 (Codefight 2).

10%: Presentation

The final presentation is on Friday 28.01.2022. Each participant in the project is supposed to give a brief presentation to a topic of choice. This applies to all participants (Informatikprojekt, Project Launch, and DDD/FAE).

  • Your presentation is supposed to be between 5 and 10 min long. We will have a strict timekeeping in place.
  • You can pick a topic of choice - the topics are the ones listed above under “Option 1: Reflection paper”
  • Please enter your matriculation number in this Google Spreadsheet, if you want to talk about this topic.

We will cluster the speakers according to topics and compile an agenda.