Mail: stefan.bente@th-koeln.de
Tel.: +49 2261 8196 6367
Skype: stefan.bente
Discord Server
Steinmüllerallee 4
51643 Gummersbach
Gebäude LC4
Raum 1708
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), 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.
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
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.

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

  • exploring the domain and defining appropriate bounded contexts for the teams,
  • 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.

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.


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.


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


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.


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

  • 20% 10% results from the pre-course (or the alternative assignments)
  • 60% 70% quality of your contribution to the project
    • One paper per subteam on mission statement part (1)
      • Event storming result documentation
      • Domain Message Flow Modelling
      • Bounded Context Canvas
      • Aggregate Design Canvas
      • Questions/answers to/from to the business people
      • Context Map for the whole picture
    • One repo with code and documentation. Documentation focuses on mission statement part (2).
      • Architecture
      • Architectural decisions
      • API specs
      • Code quality
      • Questions/answers to/from the business people and architects
    • commitment and effort (willingness to go the extra mile, to make create a great result)
    • professionalism in sprint review presentations
  • 20% final presentation Intermediate and final presentation
    • Intermediate presentation of specification results, focus on mission statement part (1)
    • Final presentation, focus on mission statement part (2)

Guidelines for the paper

Your paper should use the following chapter structure:

  • Event storming results
    • Diagram(s) with explanation
    • Open issues clarified with the business side (if any)
    • Strengths and weaknesses of the method
  • Domain Message Flow Modelling
    • Diagram(s) with explanation
    • Open issues clarified with the business side (if any)
    • Strengths and weaknesses of the method
  • Bounded Context Canvas
    • Diagram(s) with explanation
    • Open issues clarified with the business side (if any)
    • Strengths and weaknesses of the method
  • Aggregate Design Canvas
    • Diagram(s) with explanation
    • Open issues clarified with the business side (if any)
    • Strengths and weaknesses of the method
  • Context Map for the whole landscape
    • Diagram
    • Explanation for the interfaces of your own domain
    • Open issues clarified with the business side (if any)
    • Strengths and weaknesses of the method
  • Overall summary of this design approach

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

  • Base the paper on the content from your paper on mission statement part 1 (see above)
  • Focus on reflecting the tools and methods, their strengths, weaknesses, and open issues
    • Prove your points by practical examples from your own work
  • Avoid showing a long, tiring list of various canvasses :-)
  • Rule of thumb: 5 min per person (use more if needed, but don’t fill time with irrelevant details)

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

  • Translator in event storming / maintainer of bilingual glossary (for German native speakers only)
  • Event storming expert / documenter & maintainer of event storming results
  • ADR (architecture decision record) expert / maintainer of decision log
  • Expert / coach on sprint reviews
  • Expert on domain story telling


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.


  • 10:00 - 10:30:  Introduction Round
    • Every participant introduces her/himself
    • What is your knowledge level wrt. coding and DDD concepts?
    • What are your expectations?
  • 10:30 - 11:30:  Organisation of the module
    • Goal of this module
    • Structure
    • Organizational details
    • Grading
  • 11:30 - 12:15:  The DDD journey in a nutshell
    • Sketching the road ahead
    • Brief introduction into the sequence of the design elements
    • Gothaer case study briefly explained
  • 12:15 - 13:00:  Next steps
    • Pre-Qualification for those who are not familiar with DDD basic concepts (see above)
    • Tasks for those who know about DDD basic concepts (see above)

Task until next workshop

  • Work on the pre-course, or your respective tasks

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


  • 09:15 - 09:45:  Arriving on Gothaer Campus
    • We start with a management address - so please be there on time.
  • 10:00 - 10:30:  Welcome at Gothaer Insurance
    • Address by management representative
  • 10:30 - 11:30:  Case study background
    • Goals for the case study
    • Introduction to the use cases to be implemented
    • Open Space to discuss the use cases in detail
  • 11:30 - 13:00:  Event Storming Round 1
    • Big Picture workshop with business experts from Gothaer
  • 13:00 - 14:00:  Lunch Break
  • 14:00 - 14:30:  Tour of the Gothaer campus
  • 14:30 - 17:00:  Event Storming Round 2
    • Continuation of Big Picture workshop with business experts
    • taking pictures of results, for documentation

Task until next workshop

  • Document the Event Storming results in a Miro board

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


  • 10:00 - 11:00:  Introduction into the next steps from now
  • 11:00 - 12:00:  Guest Lecture "Architecture modernization with DDD, event storming and more" (Halil Hancioglu, Opitz Consulting)
    • Domain-driven design (DDD) is often used to create a domain-driven architecture. In combination with a collaborative method such as Event Storming (ES), this can quickly help to create a solution picture and promote communication in large projects. Both methods can be helpful as tools in the architect's toolbox to break down a monolith into a distributed system. However, this alone is not enough to modernize. In this guest lecture, the speaker reports on the procedure for modernizing a monolithic system in the context of e-mobility with the help of DDD, ES and other tools.
    • Halil Hancioglu works as a Solution Architect for OPITZ CONSULTING Deutschland GmbH. He has many years of experience in the creation of individual enterprise applications and the introduction of DevOps practices. His strengths lie in the analysis and restructuring of architectures with a special focus on modern IT operations.
    • Recording available here, Password will be sent on request (message to Prof. Bente)
  • 12:00 - 13:00:  Lunch Break
  • 13:00 - 15:00:  Your next steps in the project
    • Complete the event storming model, adding actors, pivotal elements, aggregates, and commands
    • Define bounded contexts
    • Organize into sub-teams, each working on a bounded context
    • Identify core / generic / support domains
    • Start planning the next steps within your subteam, 1) Domain Message Flow Modelling, 2) Bounded Context Canvas
  • 15:00 - 16:00:  Mission & Vision for the project implementation
    • Meeting with Barina Barsoum, our Technical Product Owner
    • Quick presentation of each bounded context
    • Discussion of next steps
  • 16:00 - 16:45:  Planning in your subteams
    • Finalize your planning
    • Collect questions and open issues
  • 16:45 - 17:00:  Final round to share the results
    • Closing question
    • Weekend!

Task until next workshop

  • Event storming digitized, completed, and documented (per subteam), in your Miro board
  • Domain Message Flow Modelling (per subteam), in your Miro board
  • Bounded Context Canvas (per subteam), in your Miro board
  • Glossary set up as a repo (in Gitlab called "project") under our "DDD Insurance Sandbox" organisation in Gitlab

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.


  • 10:00 - 10:30:  Agenda and orga issues
    • Agenda for today
    • Status of glossary
    • Status of pre-course
  • 10:30 - 11:30:  Specifications review and mission statement
    • Barino is (remotely) present during this part of the workshop
    • Each team presents its current status in specifications
    • (1) Event storming result documentation
    • (2) Domain Message Flow Modelling
    • (3) Bounded Context Canvas
    • Feedback from the group and from Barino
    • Discussion of mission statements for the case study (remainder of this module)
  • 11:30 - 12:00:  Concrete tasks (relevant for grading) following from the mission statement
  • 12:00 - 13:00:  Lunch Break
  • 13:00 - 14:30:  Planning per Subteam
    • Detailed planning of tasks for the next two sprints
    • Question list for the business people
    • What competences are you lacking?
    • What presentations / content impulses would you like from the professor?
  • 14:30 - 15:30:  Planning Results - What do you need to fulfill the mission statement?
    • Sharing the planning with the whole group

Task until next workshop

  • Finalization of Event storming result documentation / Domain Message Flow Modelling / Bounded Context Canvas, according to feedback
  • Question list for the business people
  • Aggregate Design Canvas
  • Paper format clarified
  • Paper started
  • Presentation planned
  • Repositories created per subteam

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


  • 10:00 - 10:30:  Guidelines for paper, presentation, glossary, and questions to business side
  • 10:30 - 10:45:  Open issues with the Aggregate Canvas
    • There are a number of open issues about the proper usage of the Aggregate Canvas (see here)
    • What exactly are "corrective policies" (field 5)? The example given in the material is a little bit inconsistent wrt. this field.
    • Where (in which field) should consumed events be listed?
    • What is the proper interpretation of fields 8 and 9 (throughput / size)? How should we, in our context, use this?
    • Goal is to come to a common understanding how to use this tool in our project.
  • 10:45 - 11:15:  Questions to the business side
    • Barino unfortunately cannot join us this Friday to answer open questions from business perspective (... or take them with him to be answered offline)
    • ... but he offered to get the questions offline, and we make a dedicated meeting with him (remote) to get them answered.
  • 11:30 - 12:00:  Open issues with modelling
    • The teams walk through their questions and open issues with their models, and try to clarify them in the larger group
  • 12:00 - 12:45:  Lunch break
  • 12:45 - 15:00:  Context Map
    • I will give a brief introduction to context map principles (ca. 30 min)
    • Then we will work as group session on the context map, on one common "Context Map" Miro board
    • Then we come together and discuss the result

Task until next workshop

  • Collect open questions to business side in our questions file, until Monday evening (28.11.)
  • Finalize Context Map, list open issues to the method and the model in our open issue file
  • Check consistency with glossary
  • Prepare presentations
  • Work on your paper (final deadline end of December)

Fri 09.12.2022, 12:30 - 15:45: Presentation of mission statement part (1)

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

Workshop Location

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

Goal of the day

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

Video recording

A video recording is available here. You know the password.


  • 12:30 - 12:50:  Presentation Address Management
  • 12:50 - 13:20:  Presentation Policy Viewer
  • 13:30 - 13:50:  Presentation Claim Submission
  • 13:50 - 14:25:  Presentation Fitness App
  • 14:30 - 15:30:  Q&A Business Side (with Barino / Michael)
  • 15:30 - 15:45:  Wrapup & next steps

Fri 13.01.2023, 12:00 - 17:00: Component Design using C4 Model

Instead of writing code, due to time constraints we will specify services using the C4 model.

Workshop Location

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

Goal of the day

Service architecture has been discussed and specified in the most important parts

Video recording

A video recording is available here. (Password: .4kN&cST).


  • 12:00 - 12:30:  The road ahead
    • Why not coding in this module?
    • Introducing the C4 Model as our way of specifying the system (instead of coding)
    • Remaining deliverables are ...
    • (1) C4 Level 1 system diagram, jointly done by all the teams
    • (2) C4 Level 2 container diagram, by each team separately
    • (3) Precise protocols (sync / async) for data exchange between the containers
    • (4) OpenAPI REST specification
    • (5) AsyncAPI Event specification
    • (6) Final presentation
  • 12:30 - 13:15:  C4 Level 1 system diagram, jointly done by all the teams
    • We use the Miro board, and work on the joint model
  • 13:15 - 14:00:  (Late) lunch break
  • 14:00 - 15:00:  C4 Level 2 system diagram, without communication protocols
    • Working in subteams in breakout sessions, designing the level 2 component view
  • 15:00 - 15:45:  Sync vs. async communication
  • 15:45 - 16:30:  Deciding communication protocols
    • Working in subteams in breakout sessions
    • Deciding communication protocols (sync / async)
  • 16:30 - 17:00:  Wrapup
    • Each subteam presents results

Task until next workshop

  • Make yourself familiar with OpenAPI
  • Create a an empty specification file in your repo
  • Make yourself familiar with AsyncAPI
  • Create a an empty specification file in your repo

Fri 20.01.2023, 10:00 - 17:00: Specifying OpenAPI and AsyncAPI, and final review

We specify the REST endpoints and events, and review everything

Workshop Location

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

Goal of the day

High level service architecture ready for implementation


  • 10:00 - 10:50:  Review C4 Model Level 1 (just us)
    • We will go through the C4 Model Level 1 drawing for an in-depth review
    • I have copied the original diagram in the Miro board and tried to "disentangle" it a bit. There are a number of software systems and relationships that need clarification (at least I had some questions)
  • 11:00 - 12:00:  Cross-Check and Sanity Check of the C4 Model Level 1 with Barino
    • Barino will join us to answer open questions
    • Goal of that session is to verify and possibly re-draw bounded context borders
    • This should be in preparation of a possible implementation as a Guided Project in the next semester
  • 12:00 - 12:45:  Lunch break
  • 12:45 - 14:00:  Revisiting level 2 for the updated bound contexts
    • We will break in subteams to revisit the level 2 diagrams
  • 14:00 - 16:30:  OpenAPI and AsyncAPI
    • First, we collect the specs to be written
    • Then we will working in subteams on the OpenAPI and AsyncAPI
    • Afterwards, we compare the results with the whole group
  • 16:30 - 17:00:  Finalization of this module
    • We discuss and decide how to document C4 and the OpenAPI and AsyncAPI specs
    • We decide on the final presentation

Fri 03.02.2023, 14:00 - 15:00: Final presentation

Presentation of the final status of the case study, and possible next development steps.

Workshop Location

Room: 0505 (Building LC6, opposite main entrance of Schwalbe Arena). In addition, there is a video conference. Video conference link: https://th-koeln.zoom.us/j/88626151854?pwd=cDdlR0IvTjVEc2FEU3M0bFV3c0IrQT09