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

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.

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
07.10.2022 - 28.02.2023. Organized as ca. 8 full-day workshops (Fridays 10:00 - 17:00), specific dates and agenda see below.
Location
The module takes place in a hybrid format. Please refer to the respective time slot or workshop day (see below on this page), to check if it is online or in presence. If there are no details given on this page, please check the other communication channels (e.g. Discord).
Video conference link: https://th-koeln.zoom.us/j/88626151854?pwd=cDdlR0IvTjVEc2FEU3M0bFV3c0IrQT09
Room 1: 0505 (Building LC6, opposite main entrance of Schwalbe Arena)
Room 2: Gothaer Insurance, Arnoldiplatz 1, 50969 Köln (We meet on the Gothaer campus in Cologne. To get there, take tram line 12 to the Pohligstrasse stop, and then walk a short distance. (See this Google maps printout for how to walk.) Call me (+49 176 8072 2689) by mobile phone in case you should run late.)
ILIAS Course for the Module
https://ilias.th-koeln.de/ilias.php?ref_id=2318807&cmdClass=ilrepositorygui&cmdNode=wc&baseClass=ilrepositorygui
Registration for the Module
Please join this ILIAS course. Registration is possible until 05.10.2022. 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.
Miro Board for documenting the Event Storming results, and the subsequent domain modelling results
During the module, you can use this Miro Board.
Discord Server for fast Communication
Discord has been proven as a very effective platform for information sharing, discussions, and consultations. Therefore, please join the ArchiLab Discord Server at https://discord.gg/YYNYb5whU8. Navigate to channel #rollenzuweisung and click on fae. Then you see all channel(s) relevant for this module.

Content

Learning Outcome

This module attempts to walk you through the design process of a relatively complex software system. This means creating 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.

Case study (and how it plays into the organization of this module)

Getting more familiar with Domain-Driven Design concepts will be a hands-on experience. You will apply the concepts in a practical case study, sponsored by Gothaer Insurance. Gothaer’s IT landscape has been grown over a period of several decades. Therefore, its IT landscape is huge, and requires constant transformation and modernization. (This situation is exactly the same with any company requiring a fairly complex IT support - insurance, banking, logistics, commerce, etc.)

Our sponsors at Gothaer want to test and validate the DDD approach in a “sandboxed approach”. They want a fraction of their IT landscape to be built in a DDD conformous fashion. The code will never go into production, but will serve as a playground to test technical concepts, and to educate Gothaer development teams. In this module, we will help Gothaer starting this code base. In return, Gothaer provides us with access to real-world use cases, business experts, and IT architects.

So we will go through a typical design process for large software systems, starting with an Event Storming onsite at Gothaer campus. The module also includes writing code, since architecture requires coding as well. The first part of the module will focus more on the business-driven DDD strategic design. The second part will bring specific technical aspects, like Event-Driven Architecture (EDA) into play.

Our process model

Our process in this module will be roughly aligned to the Domain-Driven Design Starter Modelling Process which is a pragmatic, practicioners’ guide to approaching large software design tasks.

Process Model (c) DDD Crew, CC-BY-SA-4.0

Here is how we plan to cover the phases listed in the above model in this Master course.

Align

This has basically happened already. Our main contacts on Gothaer side are from the Enterprise Architecture team, on the IT side. They have identified three use cases to be designed and implemented.

Discover

This phase is for learning about the domain, and trying to pinpoint the essence of it in a semi-formalized way.

Method used: Event Storming

Here we will use Event Storming as described in Alberto Brandolini’s popular book. This is the onsite workshop at Gothaer campus on 21.10.22, see below.

Decompose / Strategize / Organize

We will try to cover these phases jointly on 28.10.2022, by post-processing the event storming results, defining subdomains, and assigning subteams to them. This work will not be finalized on that day, but will carry over to the subsequent parts of the case study.

Method used: Domain Message Flow Modelling

The method is best described here: https://github.com/ddd-crew/domain-message-flow-modelling. It is a kind of flow diagram, depicting data / control flow to and from your (sub-)domain.

Connect / Define

The subteams will take responsibility for defining their subdomains by bounded context definitions and domain models. As a whole team, we will work on a context map for the whole project.

Method used: Bounded Context Canvas

The bounded context canvas (https://github.com/ddd-crew/bounded-context-canvas) helps to sum up the constituents of a bounded context in somewhat standardized, compact form.

Method used: Aggregate Canvas

The aggregate canvas (https://github.com/ddd-crew/aggregate-design-canvas) uses the aforementioned compact canvas style to sum up what belongs to an aggregate (as a “cluster” of correlated objects - at this stage still quite technology-agnostic). Another useful source is https://domaincentric.net/blog/modelling-aggregates-with-aggregate-design-canvas. The Vaughn Vernon blogs and his “red book” should also be mentionned, as aggregates are an important focus for him.

Some of fields of that canvas can lead to questions, like:

  1. What is the exact meaning of the “Corrective Policies” in field 5? The naive bank account example in the above description is not particularly helpful for this aspect. However, this source gives a quite plausible and sensible explanation: a corrective policy can be used to enforce violations of aggregate invariants, in case such violations are inevitable due to external events.
  2. Where should consumed events be listed? The is a field for “created events” (no. 7), but none for consumed events - although they have a big impact on how this aggregate communicates with the rest of the world. No reference found, we list it with the commands. Use colors as in event storming.
  3. How should the metrics in fields 8 and 9 be interpreted? The above mentioned Kacper Guniak blog post gives good examples here. The actual, realistic numbers should be queried from the business side.

Method used: Context Map

DDD’s strategic design goes on to describe a variety of ways that you have relationships between Bounded Contexts. It’s usually worthwhile to depict these using a context map (Martin Fowler in his very instructive post on bounded contexts). Or, as Vaugn Vernon writes in the “red book” (p. 87): “The Context Map […] is […] a simple diagram that shows the mappings between two or more existing Bounded Contexts.”

A great explanation of what context maps are can be found on Michael Plöd’s site, especially in this speakerdeck (which I present in the workshop). In addition, there is an extensive slide deck of my own, however still in German, as I haven’t translated it yet.

The DDD crew provides detailed material about context mapping. We will use their notation. However, for clarity we will combine this notation with Martin Fowler’s idea to draw the relationship pattern between aggregates, not whole bounded contexts. So it will be a combination of these two:

DDD Crew's way of drawing a context map

(c) DDD Crew, https://github.com/ddd-crew/context-mapping)

Martin Fowler's way of drawing a context map

(c) Martin Fowler, https://martinfowler.com/bliki/BoundedContext.html

Code

That last part of this course will deal with technical architecture and technical concepts, involving architectural decisions and some amount of coding. But due to the limited time budget in this course, implementing a complete solution is out of scope. Instead, those of you who find the topic interesting will have the opportunity to join a Guided Project in the subsequent semester, with the goal to finalize this case study.

Mission statement for the case study

The mission statement for the case study is twofold. The first goal is a thorough reflection on DDD as a design approach:

(1) The case study will result in a reflection considering the advantages and disadvantages of Domain Driven Design, using the design methods described in the DDD Starter Modelling Process as described above. The case study presents realistic, customer-oriented use cases in the insurance industry when integrating with existing legacy applications and standard software. The reflection will be based on research and own experiences in the design process.

The second goal is giving an answer to an important aspect of the technical architecture, implementing the case study’s bounded contexts:

(2) The case study will result in an evaluation of the suitability of event-carried state transfer when creating or changing relevant business objects, considering the integration with existing legacy applications and standard software. This paradigm for information and message exchange is to be compared with technical alternatives. The evaluation will be based on research and own experiences in coding a prototype of the functionality.

Grading

The grade for this GP will consist of the following parts:

Guidelines for the paper

Your paper should use the following chapter structure:

In addition, you should have the usual elements of a paper - a (short) introduction stating what this paper is about, plus references. It is a plus if you can back up your own reflections by external sources.

Guidelines for the intermediate presentation

Pre-course and alternative tasks

DDD is not in itself a very complex intellectual framework. But it contains a number of basic building blocks (concepts like entities, value objects, repositories, aggregates, …), which are a prerequisite for more complex design activities. In recent iterations of this course, the different levels of pre-existing knowledge turned out to be a problem.

Pre-course and learning materials

Therefore, in this course, there will be a pre-course for obtaining the “basic” knowledge. This precourse comes with a list of self-learning material, especially a dedicated video series (see video list in the workshop description below). These videos are in German, but I am in the process of adding English subtitles. As an example, see this introductory video to DDD. In addition to the videos, there will a literature list (in preparation).

You will receive a personalized Gitlab repository with a number of tasks in it - ranging from identifying entities to small coding tasks. The tasks are automatically tested by unit tests. You can solve the tasks with the help of the self-learning material.

Alternative tasks

In the TH Köln Informatik Bachelor modules Softwaretechnik 1/2, the DDD building blocks are covered extensively. Therefore, Informatik BA graduates are exempt from the pre-course. In order to be fair, they need to take over alternative tasks with roughly the same workload.

The same applies to graduates from other Bachelor programs, who can demonstrate that they have the required base knowledge - either by providing the link to a module they attended in their Bachelor program, or by showing that they have obtained that knowledge via professional experience.

The participants who are exempt from the pre-course need to work on alternative tasks with comparable workload. This is the list of alternative tasks (in descending order of priority):

Workshops

Fri 07.10.2022, 10:00 - 14:00: Kickoff

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.

Workshop Location

Room: 0505 (Building LC6, opposite main entrance of Schwalbe Arena).

Goal of the day

You can start with this module.

Agenda

Task until next workshop

Tue 11.10.2022, 14:00 - 15:00: Pre-course meeting

I present you the repository to work on during the pre-course phase, answer your questions, and we discuss touchpoints (how you organize your work, how you get help, etc.)

Workshop Location

Video conference link: https://th-koeln.zoom.us/j/88626151854?pwd=cDdlR0IvTjVEc2FEU3M0bFV3c0IrQT09 .

Goal of the day

You can start with the pre-course.

Video recording

A video recording is available here.

Please watch the following video(s) beforehand

Fri 21.10.2022, 09:15 - 17:00: Event Storming @ Gothaer

We meet at the Gothaer campus in Cologne, and perform an Event Storming there to explore the details of our case study. Real Gothaer business experts will participate.

Workshop Location

Room: Gothaer Insurance, Arnoldiplatz 1, 50969 Köln (We meet on the Gothaer campus in Cologne. To get there, take tram line 12 to the Pohligstrasse stop, and then walk a short distance. (See this Google maps printout for how to walk.) Call me (+49 176 8072 2689) by mobile phone in case you should run late.).

Goal of the day

We have an initial understanding of the case study

Agenda

Task until next workshop

Fri 28.10.2022, 10:00 - 17:00: Event Storming post-processing

We evaluate the Event Storming results and derive service boundaries and backlogs from them.

Workshop Location

Room: 0505 (Building LC6, opposite main entrance of Schwalbe Arena).

Goal of the day

We are ready to start software design

Agenda

Task until next workshop

Fri 11.11.2022, 10:00 - 17:00: Bounded context detailed specification

We review the current status of bounded context specification work, and plan the tasks ahead.

Workshop Location

Room: 0505 (Building LC6, opposite main entrance of Schwalbe Arena).

Goal of the day

We are ready to start looking into the technical architecture.

Agenda

Task until next workshop

Fri 25.11.2022, 10:00 - 15:00: Finalization of High-Level Design Phase

We reflect the artifacts for the high-level design phase, and clarify open questions.

Workshop Location

Video conference link: https://th-koeln.zoom.us/j/88626151854?pwd=cDdlR0IvTjVEc2FEU3M0bFV3c0IrQT09 .

Goal of the day

We are ready to create presentations and papers

Agenda

Task until next workshop

Fri 09.12.2022, 10:00 - 14:00: Presentation of mission statement part (1)

Each subteam presents the results from its specification paper, including the reflection on approach and methods.

Workshop Location

Room: 0505 (Building LC6, opposite main entrance of Schwalbe Arena).

Goal of the day

Customer is informed about progress and has given constructive feedback to the teams

Agenda

Task until next workshop

Fri 13.01.2023, 10:00 - 14:00: Sprint review / planning

Bi-weekly review & planning meeting, optionally with a guest lecture.

Workshop Location

Room: 0505 (Building LC6, opposite main entrance of Schwalbe Arena).

Goal of the day

Customer is informed about progress and has given constructive feedback to the teams

Agenda

Task until next workshop

Fri 20.01.2023, 10:00 - 17:00: Final presentation

Presentation of the final status of implementation, and the next development steps have been roadmapped so that a Guided Project could pick up from there.

Workshop Location

Room: 0505 (Building LC6, opposite main entrance of Schwalbe Arena).

Goal of the day

Customer knows about the final status of this project phase, and the proposals for a development roadmap.

Agenda