Page tree

Lecture "Fachspezifischer Architekturentwurf (FAE)", Master Computer Science / Software Engineering, WS 19/20. (The lecture program for past WS 18/19 can be found here.)

Timetable and Content

Notes:


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

Fr 11.10.

12:00-16:00

0501

(0)
Archi-tecture Rules

Kickoff

  • 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
-
2

Do 17.10.

10:00 - 13:00

0503

(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), 

confirmed

  1. Eventstorming as method for domain exploration

-

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

Fr 25.10.

12:30-16:30

0501

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

confirmed

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

Fr 01.11.

Public Holiday (Allerheiligen)
6

Do 7.11.

10:00 - 13:00

3109

(2)
Archi-tecture Goals

(3) Micro-service precon-ditions

(4)
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
7

Fr 8.11.

12:30-16:30

0501

-

Q&A for Coding / Configuration Problems

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

-

-

-

8

Fr 15.11.

12:30 - 16:30

0501

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

confirmed


  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
9

Fr 22.11.

12:30 - 16:30

0505

NEW!

(2) - (3)
Docker-ization 

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
10

Fr 29.11.

12:30-16:30

0501

(1) Under-standing the Domain

(4)
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
11

Fr 06.12.

12:30-16:30

0501

(5)
REST

(6)
Eventing

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)

confirmed


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

Fr 13.12.

12:30 - 16:30

0501

(5)
REST

(6)
Eventing

REST Beyond The Obvious - API Patterns

  • Stefan Bente , Marc Schmidt
  • Rules for REST APIs
  • Maturity model according to Richardson, esp. level 2 vs. level 3
  • Why is it sensible to use REST level 3 with a RDM?
  • Good practices: what-to-use-when
  • CQRS
  • Using Spring Boot for REST APIs

Eventing with Apache Kafka

  • Introduction to implementing events using Kafka
-
  • Teams revisit their event storming notes
  • build state diagrams
  • derive level 3 API structure from there, where sensible
  • REST API in level 3 specified & documented
  • REST API implementation tested using Postman, included in CD
  • Event implementation started
13

Fr 20.12.


Xmas Break

14Fr 27.12.
15Fr 03.01.
16

Fr 10.01.

12:30 - 16:30

0501

(6)
Eventing

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)

confirmed


  • Teams define events (provider) and connect to message broker
  • Teams select events to be consumed and implement a listener
  • events specified for exemplary services
  • some services connected to message broker (provider & consumer)
17

Do 16.01.

10:00 - 13:00

3109

(0) - (7)
for Research Project INTIA

Outlook: Roadmap for INTIA Project

  • Use the foundations laid in both courses (Bente, Zorn) to work out a roadmap for INTIA
  • Prework on Social Worker side:
    • Identify areas for software solutions in INTIA
    • Collect goals, chances, constraints, obstacles, risks

Joint workshop with Social Workers (Prof. Zorn), 

confirmed

  • Social Workers and INTIA team present INTIA situation to FAE participants
  • Mixed subteams are formed, grouped by possible application areas (e.g.: digital task book, social app)
  • Subteams discuss roadmaps with ELSI and technical aspects
  • Document how FAE results for ILA can be used in INTIA
18

Fr 24.01.

12:30-16:30

0501

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

confirmed

  • Teams discuss the best UI paradigm, and sketch the UI
  • Simple UIs sketches documented
  • UI architecture described
19

Fr 31.01.

12:30-16:30

0501

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

Summary and Conclusion

  • Presentation by each team
  • next steps



20

Mo 3.2.

12:00 - 17:00

tbd


Oral Exams



Parallel to the lectures, the students work in subteams on a case study. The following table sums up all relevant URLs for each subteam.


Shared Timeslots with F01 Seminar "INTIA Lehrforschungsprojekt"

FAE shares two timeslots with a seminar in faculty 01, due to the connection via research group DITES

M15 "D" INTIA - Lehrforschungsprojekt im Forschungsschwerpunkt Digitale Technologien und Soziale Dienste DITES im Rahmen eines Projekts des Bundesministeriums für Bildung und Forschung (SAB/M15)

Dozent/in

Prof. Dr. phil. Isabel Zorn

Angaben

Seminar, 4 SWS
Zeit und Ort: Do 9:45 - 13:00, Raum n.V.
vom 3.10.2019 bis zum 16.1.2020

Lernziele / Kompetenzen

Können digitale Tools in der Arbeit mit Klientinnen der Sozialen Arbeit genutzt werden, z.B. ein GPS-Tracker, um BewohnerInnen freien Ausgang zu gewähren, Tagesplaner in der stationären Jugendhilfe um Strukturierungen zu üben u.a.? (Junge) Menschen in stationären Einrichtungen der Hilfen zur Erziehung oder in der Eingliederungshilfe sind in geringerem Maße in die digitale Welt eingebunden, was für sie weniger digitale Teilhabe und Verluste an möglicher Alltagserleichterung bedeutet; Fachkräfte wurden in ihrer Ausbildung nicht ausreichend auf den digitalen Wandel und die damit verbundene digitalisierte Alltagswelt vorbereitet.

Lehrinhalte

Das Seminar untersucht Risiken und Chancen neuer Technologien und kreativer Lösungen zur Erfüllung der Aufgaben Sozialer Arbeit anhand Theorien der Ziele und Aufgaben Sozialer Arbeit und Analysen der Handlungsfelder Jugendhilfe und Eingliederungshilfe. Es ist eingebunden in ein Forschungsprojekt (INTIA) des Bundesministeriums für Bildung und Forschung. Wir erforschen fakultätsübergreifend, wie Fachkräfte der Sozialen Arbeit sowie Adressatinnen als Expertinnen ihrer selbst an inklusiven Technologieentwicklungsprozessen teilnehmen können und werden unterstützt durch Forschende und Studierende aus Informatik und Design. Alltagsrelevante Hilfe- und Teilhabebedarfe werden durch uns identifiziert. Die Zielgruppen sollen im Projekt in die Lage versetzt werden, technologische Lösungen selbst zu erfinden, zu gestalten, anzupassen und so Selbstwirksamkeit zu erleben. Wir setzen dafür unsere Kenntnisse über gruppenbezogenen Methoden, Ethik, Selbstbestimmungsmöglichkeiten, Recht, Beratung, Medienpädagogik, kreative Ausdrucksmöglichkeiten usw. ein. Wir entdecken Technologien. Wir begründen unsere Vorgehensweise theoriegeleitet und analysieren Auswirkungen von Digitalisierungsprozessen auf Organisation, Fachkräfte und Adressatinnen. Im Seminar lesen wir spannende Texte, sehen Filme, diskutieren und suchen nach Handlungsmöglichkeiten. Gesellschaftskritische, machttheoretische, organisationstheoretische Perspektiven werden mit pädagogischen, sozialarbeitstheoretischen und informatischen Perspektiven verknüpft. Ihre Erfahrungen aus der Praxis werden eingebunden. Ein interdisziplinäres Element des Seminares wird sein: Ein Workshop mit Studierenden der Fakultät für Informatik, die mit Adressatinnen (und evt mit uns) ein Tool entwickeln, das wir kritisch prüfen werden aufgrund unserer Theorieexpertise, wird in interdisziplinären Tagesworkshops erfolgen. Das Seminar läuft über 2 Semester. Die Durchführung von eigenen Bedarfserhebungen und eigenen Workshops in weiteren Einrichtungen ist denkbar.

Methodische Anmerkungen

Prüfungsleistung: Hausarbeit oder Konzeption oder Forschungsexposé

Zusätzliche Informationen

Erwartete Teilnehmerzahl: 30