Fachspezifischer Architekturentwurf (FAE) im WS 19/20

"Fachspezifischer Architekturentwurf (FAE)" is a course in Master Computer Science / Software Engineering study program. This page refers to WS 19/20. For further details and learning material please refer to the subpages:

Learning Outcome

After completing FAE, the following statement should be true for the particapating students. 

  • As an experienced programmer or architect
  • I can design and implement a reasonably complex greenfield application in a multi-team approach, using the microservice paradigm,
  • by 
    1. exploring the domain and defining appropriate bounded contexts for the teams,

    2. picking the suitable architectural style, according to the goals of for my software,

    3. understanding the organisational preconditions wrt. DevOps,

    4. defining service boundaries,

    5. defining and implementing REST APIs in a suitable style,

    6. defining and implementing events, using the appropriate architecture patterns,

    7. roadmapping the UI architecture, and

    8. reflecting my architecture and development process

  • so that the prototype that is jointly created during the course is sound and sustainable wrt. architecture and coding style.

Timetable and Content


Date7 Cross-roadsLecture / Presentation PartExternal Speakers / ParticipantsGroup Work PartResult(s) to Be Presented Next Course Meeting

Fr 11.10.



Archi-tecture Rules


  • 7 Crossroads in modern SW development
  • Course structure, time schedule, further organizational details, grading criteria
  • Marc Schmidt Rules for result documentation
    • Architecture Documentation (Github)
    • Decision Log
    • Glossary
  • Jann Intveen: Introduction to coding infrastructure
  • Subteam formation


  1. Definition of 4 subteams

Do 17.10.

10:00 - 13:00


(1) Under-standing the Domain

Domain Exploration & Event Storming

  • Discussion of domain
  • Challenges, risks, chances
  • What should we look for? Where do we need to apply extra care?
  • Event Storming 

Joint workshop with Social Workers (Prof. Zorn), 


  1. Eventstorming as method for domain exploration


3Fr 18.10.no lecture (due to Thursday timeslot)

Fr 25.10.



(1) Under-standing the Domain

Domains and Bounded Contexts

  • Introduction to DDD core concepts
  • Practical advice for domain and bounded context analysis (good practices, rules of thumb for size, …)

Annegret Junker (adesso)


  1. Finalization of Event Storming
  2. Identification of subdomains
  3. Subteams pick their subdomain to work on

Each subteam documents the following in the wiki of its own Github repo:

  1. results from Event Storming (in written form)
  2. a domain vision statement in the  (see glossary definition here)
  3. a first version of its own domain model (see glossary)
  4. glossary entries for the domain model elements and other important terms (see here for instructions how)

Fr 01.11.

Public Holiday (Allerheiligen)

Do 7.11.

10:00 - 13:00


Archi-tecture Goals

(3) Micro-service precon-ditions

Service size

Architecture For Agility

  • "What is this all about"? Relationship between domain-driven design, agility and organization structure
  • DevOps as preconditions for MS architecture
  • Core Microservice principles (loose coupling, you build it / you run it, freedom of technology choice, …)
  • Approach when modelling services (e.g. "Bounded Context or Aggregate = service" as a design starting point)
  • Service size (developer anarchy vs. self-contained system)

Spring Boot as Base for Microservices

  • Jann Intveen
    • Intro to Spring Boot & Hibernate
    • Configuration of Deployment Pipeline
    • Tests
  1. Setup of own dev env
  2. Teams start to transform BC into JPA annotated entities
  3. Teams start to implement simple CRUD services
  1. simple CRUD services ready to show

Fr 8.11.




Q&A for Coding / Configuration Problems

  • No regular lecture on this timeslot
  • Just possibility to work and ask questions





Fr 15.11.

12:30 - 16:30


(0) - (7)
for Rewe Digital

Microservice Migration in a Brownfield Project

  • What kind of organizational structure do you need to reflect the vertical boundaries in software while growing fast?

  • How do you define bounded contexts with many teams and features? Are there ways to guide your teams and enable autonomy on all levels in your organization?

  • Can you enable your teams to develop and deploy independently all the way to production?

  • How does asynchronous communication with Apache Kafka change the way you think about your entities?

  • How can multiple microservices contribute to the same pages? (And why you might have to implement this twice...)

Ansgar Schulze Everding (Rewe Digital)


  1. Discussion of lecture,  roadmapping for own sub-domain (=> wiki!)
  2. Agreement on team time tracking for later evaluation
  3. Consolidation of glossary entries
  4. Update of domain model:
    1. integration / clustering of events
    2. decision: which entities does our subdomain own, what do we require from others?
  1. In wiki: Roadmap for further steps in this project
  2. Team time tracking decided & described in local decision
  3. Update of glossary items
  4. Updated domain model

Fr 22.11.

12:30 - 16:30



(2) - (3)

NEW! Introduction to Docker

  • Intro / live demo: How can we package our code as Docker container?
  • And how to deploy it to the build pipeline?
  1. Teams set up Docker containers and build pipeline configuration
  1. Running software in browser, can be queried using Postman

Fr 29.11.



(1) Under-standing the Domain

Service size

Summary / Recap, So Far

  • Teams present their current status
  • Joint discussion of guidelines and glossary
  • brief presentation of current status
  1. All feedback comments addressed
  2. Decisions and glossary updated (please take into account changes to domain boundaries, as discussed between the subteams!)
  3. Event documentation complete
  4. Events mapped to entities in domain model
  5. High level REST API design available, based on events
  6. CRUD REST API unter archi-lab.io accessible

Fr 06.12.





API Ecosystems

APIs are omni-present nowadays and an important vehicle for enterprises to broaden their product offerings. Form an IT perspective, an API-led architecture is key to react on changed business requirements in an agile fashion. An API design-first approach is key to enable this kind of agility, especially with regards to µServices architectures and DevOps.

During the session, we’ll take a look at the following points:

  • Meaning of APIs in a µServices architecture
  • API Interaction patterns (Synchronous/asynchronous APIs, events)
  • Consistent API design & API design-first approach
  • API life cycle and how to incorporate it with a DevOps approach
  • Characteristics of API-led architectures (Basic architecture components like API Gateways)
  • API implementation (Alternative approaches to REST (GraphQL, gRPC), Reactive vs. Non-reactive API implementations)

Besides the respective theoretical concepts, we will look into some practical examples to make aspects of the concepts more transparent.

Sven Bernhardt (Opitz)


  • Teams discuss their API strategy with regard to "big picture"
  1. Take Open API 3.0 into use in your service to model and mock your REST APIs
  2. Model the events mapped in your domain model using Apache Avro (and generate the corresponding classes). This is supposed to be a PoC (proof-of-concept) to validate if this works for us.

Fr 13.12.

12:30 - 16:30




API Documentation - Open API 3.0

  • Status teams
  • Technical Intro
  • global / guiding decision?


  • Maturity Level 2 vs. 3
  • Using state diagrams as input for REST API development – group exercise
  • Spring Data REST as alternative


  • Kafka setup 
  • New service to simulation GPS tracker movement
  • Avro experience - global / guiding decision?
  • First steps towards integration


  • System workflow simulation with Node Red 
  • Teams revisit their event storming notes, build state diagrams, decide on which style to use
  • Teams discuss their overall APIs (REST, events) and business logic: Is it sufficient to model the dummy UI scenario(s)?
  1. REST API decisisions and structures specified & documented, endpoints available
  2. Event structure  specified & documented, Kafka topics implemented 
  3. UI Dummy in Node Red implemented


Fr 20.12.

Xmas Break

14Fr 27.12.
15Fr 03.01.

Fr 10.01.

12:30 - 16:30



Transactions between Microservices

  • Transaction patterns (event sourcing, Saga pattern, interaction between REST and messaging)
  • Introduction to messaging and frequently used technologies

Sebastian Gauder (Rewe Digital)


  • Teams revisit their events (provider, consumer) and connection to message broker
  • Possibility to discuss technical difficulties
  1. Continuation of integration work as described above. 
  2. Goal: Scenarios are fully implemented, and can be demonstrated

Do 16.01.

10:00 - 13:00


(0) - (7)

Analysis of Social Impact and Ethical Aspects of ILA

  • Analysis of social impact and ethical aspects of ILA 
  • Application of a new analysis approach currently under research at ArchiLab
    1. Risk + goal analysis wrt. social & business impact factors
    2. Collection of requirements that help to mitigate risks & achieve goals
    3. Analysis of technical implications for the subdomains
  • Method is supported by custom-tailored Excel sheet (provided on Thu)


  1. Include "your" Excel as a link in your Github wiki
  2. Briefly sum up your main findings from the group discussion process in your wiki (2-3 sentences is sufficient)

Fr 24.01.



Mono-lithic UI vs. Micro-Front-ends

UIs in a Microservice Landscape

  • Popular MS patterns to connect UIs: API Gateway, Backend for Frontend
  • Do’s and Don’ts when connecting clients
  • UI integration concepts (HTML links, monolithic UIs, client / service side composition, Micro Frontends, ...)

Wolf Schlegel , Niko Hellwig (ThoughtWorks)


  • Teams discuss the best UI paradigm, and sketch the UI
  • Reflection in the documentation: How appropriate is the UI structure as induced by the Node Red based dummy UIs?

Fr 31.01.



(0) - (7)
as a Retro-spective

Summary and Conclusion

  • Presentation by each team
  • Feedback
  • Questions & Comments


Mo 3.2.

12:00 - 17:00


Oral Exams