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 “scaffold” implementation. Aspects of a technical architecture are not covered in this course.
#rollenzuweisung
and click on
ddd.
Then you automatically get access to the channel(s) relevant for this module.
This module attempts to walk you through the design process for a relatively complex software system, by creating a domain-specific design for the problem. Modern software architecture means that you are close to coding. Therefore, we will have a real software development case study in this module.
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.
Domain-Driven Design (DDD) is a concept framework rather than a design method. In order to give this course a practical, hands-on approach, we will use the DDD Starter Modelling Process as a process model. This is a multi-phase process, which we will divide in the three parts listed below. The list also contains the artifacts that we will create in this course (as indented bullet points).
You will basically work in two subteams in this course.
The case study will be a restaurant management system, as described in the case study description.
(tbd - there will be repository for code and documentation)
(tbd - detailed grading scheme)
The grading will be based on the following aspects:
As a default, I assume that each team member contributes an equal share to the team project. However, if I have indications that this is not the case, I reserve the right to adjust the individual grades accordingly. In such a case, I will modify the team points for the individual score according to the following table.
| Individual Contribution | < 30% | 30 … 80% | 80 … 100% | > 100% |
|---|---|---|---|---|
| Level of individual contribution to team efforts | The student was hardly involved in any interactions at all within the team. | The student was only involved in team interactions on a few occasions. | The student has been visible to an average degree in the team (guiding others, leadership tasks, providing assistance, contributing to professional discussions, etc). | The student has been exceptionally visible in the team through guidance of others, leadership roles, assistance, contributions to professional discussions, and the like. |
This concerns the following the workshop and the final presentation aspects, which are group grades. The case study grade points are based on individual contributions, as per effort matrix.
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.
Room: 0505 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions.
You can start with this module.
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.
We evaluate the EventStorming results and derive bounded contexts (the blueprints for service boundaries) from them. We apply selected elements of the "DDD Crew" toolset, prepared and facilitated by a dedicated "DDD Crew" subteam. I will coach and support the moderators.
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.
Based on the bounded contexts, we will now create a high-level C4 model. This workshop is prepared and facilitated by a dedicated "C4 model" subteam. I will coach and support the moderators.
Room: 0505 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions.
You have a technical model of a modulith 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.
We will start implementing a prototype for our case study using Spring Modulith. The workshop will give you an in-depth introduction to the framework and the conceptual ideas behind it.
Room: 0505 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions.
You have a good understanding how Spring Modulith works, and how to use it to implement a DDD-based architecture. You have organized yourself in subteams, and have a plan how to proceed with the implementation.
We will review the status of the implementation, and discuss obstacles and the next steps.
Room: 0505 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions.
You can continue with the implementation, and have a plan how to proceed.
We will showcase the implementation results, and reflect on the methodology behind it.
Room: 0505 (Building LC6, opposite main entrance of Schwalbe Arena), see also detailed directions.
You have an educated opinion on the pros and cons of the DDD conceptual ideas and tools, and can apply it in your own projects.