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.
Location
The module (usually) takes place in a purely online format.
Video conference link: https://th-koeln.zoom.us/j/88910722611?pwd=cXd0RzZMTzBrR0xZRU9hRnp5MVdQQT09
ILIAS Course for the Module
https://ilias.th-koeln.de/ilias.php?ref_id=987028&cmdClass=ilrepositorygui&cmdNode=wc&baseClass=ilrepositorygui
Registration for the Module
Please join this ILIAS course. Registration is possible until 12.09.2021. The maximum number of participants is 15. If there are less than 3 participants the event cannot take place. 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.

Content

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 ...

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.

Organization

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 Event Storming - Understanding main DDD concepts
- Participation in Event Storming
- 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:

“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:

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.

Infrastructure

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:

Schedule

  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 Event Storming - Big Picture
3 Mon 04.10. 10:00 - 17:00 CoCo S22 Event Storming - Details
4 Tue 05.10. 10:00 - 17:00 CoCo S22 Event Storming - 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

Grading

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.

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

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  

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).

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