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.
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 ...
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 |
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:
“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:
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.
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:
Psychological aspects of digital transformation (PADT) by Prof. Dr. Dr. Palmer
| 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.
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.
You don’t have to submit anything here. I will just review your contribution until 28.01.2022.
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 |
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 |
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).
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).
We will cluster the speakers according to topics and compile an agenda.