Fachspezifischer Architekturentwurf (FAE)

FAE ist eine Veranstaltung im Wintersemester des Informatik Master. Diese Seite (mit den entsprechenden Unterseiten) wird fortlaufend aktualisiert. Es wäre also sinnvoll, wenn Sie die Seite bookmarken.

FAE - Aktuelles

Als Vortreffen treffen wir uns am Montag 04.01.21 um 17:00 zur Vorbesprechung. Hier sind die Einwahldaten: 

Der erste reguläre Workshop ist am Fr 8.1. ab 10:00. 

Ihre persönliche Todo-Liste in Vorbereitung auf die Veranstaltung

Bis zum Freitag 8.1. (inklusive, geht also noch während des Workshops!) sollten Sie die folgende Vorbereitungsliste abgeschlossen haben. 

  1. Treten Sie dem ILIAS-Kurs zur Veranstaltung bei.
  2. Lesen Sie sich die Vorab-Informationen zur Fallstudie durch. 
  3. Entscheiden Sie sich dann für eines der Development Teams (DevTeam), für die in ILIAS Gruppen angelegt sind. Jedes DevTeam ist für eine Subdomäne zuständig. Diese sind unter Fallstudie kurz beschrieben. Wir besprechen das noch am Freitag im Workshop, da können Sie sich noch ein genaueres Bild machen. 
  4. In der gleichen Weise sollten Sie für eine Special Interest Group (SIG) entscheiden, für die es auch schon ILIAS-Gruppen gibt. Näheres dazu unter Special Interest Groups

Ziele und Struktur der Veranstaltung

Ziel der Veranstaltung ist, wie der Name sagt, einen "fachspezifischen Architekturentwurf" für eine definierte Fallstudie nach dem Ansatz des Domain-Driven Designs (DDD) durchzuspielen. Eine moderne Auslegung von Softwarearchitektur beinhaltet, dass man nahe am Coding ist und Design Decisions basierend auf Recherche und praktischer Erfahrung trifft. Daher versuchen wir in dieser Veranstaltung, so nahe wie möglich an einem echten Entwicklungsprojekt mit seinen Architekturentscheidungen zu sein. 

Learning Outcome 

Das Lernziel für die Veranstaltung kann wie folgt zusammengefasst werden: 

  • As an 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 ...
    • exploring the domain and defining appropriate bounded contexts for the teams,
    • picking the suitable architectural style, according to the goals of for my software,
    • understanding the organisational preconditions wrt. DevOps, 
    • 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 the prototype that is jointly created during the course is sound and sustainable wrt. architecture and coding style.

Die Bearbeitung wird in Form von Workshop mit Inhaltsimpulsen (Videos, Kurzvorträge durch den Dozenten, Gastsprecher) sowie einer Fallstudienbearbeitung stattfinden. 

"Simulation" einer echten Projektsituation als Community of Practice

Das ist eine Herausforderung. In einem typischen Greenfield-Entwicklungsprojekt gibt es ein Architekturteam von 2-3 Personen und eine Entwicklungszeit von 12 - 24 Monaten. Wir haben 15 - 20 Teilnehmer*innen, die alle an den Entscheidungen aktiv mitwirken sollen, und eine Bearbeitungszeit von 6 - 8 Wochen (bei zwei Arbeitstagen pro Woche, siehe Zeitplan). Daher müssen wir ein Konstrukt wählen, das eine Architektur- und Projektarbeit in diesem Setting zumindest "annähernd" realistisch abbildet. Dies wird nach den folgenden Regeln passieren. 

  1. Jede/r von Ihnen ist Mitglied eines Development Teams (DevTeam). In diesem Team implementieren Sie Funktionalität Ihrer Subdomäne.
    • In Ihrem DevTeam handeln Sie einen gemeinsamen Arbeitstag aus (NICHT der Freitag, sondern zusätzlich dazu).
    • Dieser Arbeitstag gehört nur der Recherche, Diskussion, Implementierung und Test von Funktionalität aus Ihrer Subdomäne.
    • Die Arbeit in Ihrem Team planen und organisieren Sie selbst, mit Hilfe von Github Issues. 
    • An den Sprint-Freitagen stellen Sie den Fortschritt Ihres DevTeams dar. 
  2. Darüber hinaus ist jede/r von Ihnen Mitglied einer Special Interest Group (SIG), die sich mit Cross-Cutting-Concerns beschäftigt. Diese sind weiter unten beschrieben. 
    • Diese SIGs tagen an den Freitagen. In ihnen werden die Architekturentscheidungen besprochen. 
    • Es gibt eine vorläufige Liste von zu treffenden Entscheidungen (Architecture Decision Log), die sich sich sicher noch erweitern wird.  
  3. Sie bearbeiten allein oder in einem Zweier-Team die Architecture Decisions und bereiten diese soweit auf, dass Ihre SIG eine Entscheidung treffen kann.
    • Am Schluss müssen die Stakeholder zustimmen. Siehe auch die Fallstudie
    • Damit machen Sie dann für alle verpflichtende Vorgaben oder sprechen Empfehlungen aus. 
    • Sie können sich dafür entscheiden, in der Veranstaltung als Teil eines festen Pairs zu arbeiten. Pair Programming und Pair Design wird begrüßt.

Am Schluss der Veranstaltung sollte ein funktionsfähiger Prototyp des Backends stehen, plus einem tragfähigen Architecture Decision Log

Special Interest Groups (SIG)

Es gibt drei SIGs:

  • APIs
  • Eventing
  • DevOps

Damit können wir die meisten unserer Cross-Cutting Concerns einer SIG zuordnen. Die SIGs sind die Gremien, in den Architecture Decisions diskutiert und vorgeschlagen werden.

Architecture Decision Log

Alle Architektur-Entscheidungen werden hier verwaltet: https://evatool.github.io/fae-architecture-log/

Die Lösung basiert auf Github Pages und liegt in diesem Repo: https://github.com/EVATool/fae-architecture-log

Bewertung

Die Bewertung setzt sich aus verschiedenen Teilen zusammen. Die Prozentzahlen bemessen sich in etwa an dem jeweiligen Aufwand. 

BewertungsteilAnteilGruppe/einzeln
Qualität der im DevTeam entworfenen und implementierten prototypischen Lösung30%DevTeam
Qualität und Umfang der betreuten Architecture Decisions30%individuell oder im Pair
Abschlusspräsentation20%Gesamtteam
Fachgespräch20%individuell

Fallstudie

Gegenstand der Fallstudie ist die Entwicklung eines Ethik Assessment Tools für Softwareprojekte. 

Hintergrund ist folgender: Zu dem Thema habe ich einen Vortrag auf der OOP 2020 gehalten, der einiges Interesse und zwei Fachartikel nach sich zog. In dem Vortrag habe ich ein Tool skizziert (als Excel- und VBA-basierte Demo). Dr. Peter Klein von der Firma UID hat den iX-Artikel gelesen und mich kontaktiert. UID wird ein solches Tool als Open-Source-Lösung entwickeln, mit dem Fokus auf das Frontend. Wir werden in dieser Veranstaltung die Grundlage für das Backend legen. 

Hier sind einige Links zum Nachlesen und -schauen: 

Subdomänen

Wir werden für die Entwicklung von vier Subdomänen ausgehen, um die sich jeweils ein DevTeam kümmern wird. 

  1. Goals & Risks
    • Aggregates: GoalRisk, AssessmentSystem, ...
  2. Projects
    • Aggregates: User, Analysis, UserProfile, Stakeholder, ...
  3. Requirements
    • Aggregates: Requirement, DevelopmentDimension, ...
    • zusätzliche Funktionalität: JIRA-Export
  4. Scenarios
    • Aggregates: Scenario, ...
    • zusätzliche Funktionalität: Dashboard

Zeitplan und Aufwand

Die Veranstaltungen Interaction Design (Prof. Dr. Hartmann) und FAE liegen im Stundenplan beide auf dem Freitag (ID vor-, FAE nachmittags). Kollege Hartmann und ich haben uns verständigt, dass wir lieber weniger Veranstaltungstage haben möchten, dafür dann aber ganztägige Workshops. ID wird daher alle Freitage bis Weihnachten nutzen. FAE beginnt dadurch erst im Januar.

Aufwand

Der Umfang von 6 CP (180h) wird sich bei dieser Veranstaltung in etwa wie folgt verteilen: 

Phase

Aktivität

Typ

Aufwand (h)

in Arbeitstagen

KickoffEinführung ins Thema, Einlesen, Teamorganisation Gruppenarbeit mit Kontaktzeit / Selbststudium202,5
ProjektbearbeitungSprints mit festen Arbeitstagen im Team und Freitags-WorkshopsInhaltsimpulse durch Dozent / Gruppenarbeit mit Kontaktzeit / Selbststudium9612
AbschlussFertigstellen der Dokumentation und sonstige abschließenden ArbeitenSelbststudium162

Abschlusspräsentation mit VorbereitungGruppenarbeit mit Kontaktzeit / Selbststudium243

Vorbereitung des FachgesprächsSelbststudium243
Summe

180 (6 CP)22,5

Zeitplan

Der Zeitplan wurde durch eine Umfrage unter den Teilnehmer*innen eindeutig entschieden. In jedem Fall ist gemäß Stundenplan der Freitag ein FAE-Workshoptag; weitere Arbeitstage können individuell in Untergruppen ausgehandelt werden. Die Veranstaltung geht vom 4.1. bis zum 19.2. (danach dann noch Fachgespräche und eine Abschlusspräsentation). Für die Veranstaltung müssen Sie in dieser Zeit fest zwei Arbeitstage pro Woche einplanen. Wir werden die Fallstudienbearbeitung und die inhaltlichen Workshops in Sprints gliedern - in diesem Fall wären es 3 Sprints zu je 2 Wochen Dauer (siehe Bild). 


Workshops

Freitag, 08.01.2020 - Kickoff

Für den ersten Workshop am 8.1. stehen folgende Themen auf der Tagesordnung.

Zeit (ca.)InhaltWer
10:00 - 11:00Intro
Einführung Thema der Fallstudie
Bente
11:00 - 12:00

Fallstudie detailliert: EVATool-Frontend

  • Vorstellung UID/Team
  • Kurze Beschreibung unserer Standard Vorgehensweise (Scenario Based Design)
  • Bisherige Projektartefakte vorstellen:
    • Szenarien
    • Persona
    • Wireframe
    • Visual Design
  • Fragen/Diskussion
Dr. Peter Klein (UID)
12:00 - 12:30Orga (Discord, Github)
Entscheidung für Development-Team
alle
12:30 - 13:30Mittagspause
13:30 - 14:00

Ziele der Veranstaltung
Entwicklungs- / Architektur-Prozess vorstellen
SIGs vorstellen

Bente
14:00 - 15:00Entscheidung für SIG
Diskussion und Brainstorming innerhalb der SIGs: Welche Entscheidungen sind zu treffen?
alle (in SIGs als Untergruppen)
15:00 - 16:00Liste der Architectural Decisions durchgehen
Vervollständigen
nächste Schritte
alle
Bente (moderiert)

Vorbereitung auf den Workshop

Bitte machen Sie in Vorbereitung auf den Workshop die folgenden Schritte. 

Freitag, 15.01.2020 - Planung in SIGs und Teams

Beim zweiten Workshop am 15.1. wird es darum gehen, die Aktivitäten in SIGs und Teams zu koordinieren und zu planen. 

Zeit (ca.)InhaltWer
10:00 - 10:45

Diskussion Umfrageergebnisse zur Selbsteinschätzung -
Wünsche an Inhaltsimpulse

alle
10:45 - 11:30Inhaltsimpuls: Modulith als Architekturstil für unser SystemBente
11:30 - 11:45Möglichkeiten zur TaskplanungBente
11:45 - 12:00Stand des Architecture Decision Logs
Trial Repo
Bente / alle
12:00 - 13:00SIGs: Diskussion und Planung in SIGsUntergruppen (SIGs), Discord
13:00 - 13:45Mittagspause
13:45 - 14:15SIGs: Vorstellung der Planung und Decisionsalle
14:15 - 15:30Teams: Diskussion Domain Model, TaskplanungUntergruppen (Teams), Discord
15:30 - 16:00Teams: Vorstellung der Planungalle

Freitag, 22.01.2020 - Development Kickoff

Beim dritten Workshop am 22.1. konzentrieren wir uns darauf, mit der Entwicklung zu starten.

Zeit (ca.)InhaltWer
10:00 - 11:00

Offene Punkte, Ergänzungen Agenda für den Workshop

"Basic Decisions": 

alle

Bente

11:00 - 12:00Aktueller Stand der UI-Prototyps - Gelegenheit zu Fragen und DiskussionKlein
12:00 - 12:45SIGs: Arbeit an den Architecture DecisionsUntergruppen (SIGs), Discord
12:45 - 13:45Mittagspause
13:45 - 15:00SIGs: Arbeit an den Architecture DecisionsUntergruppen (SIGs), Discord
15:00 - 16:00Vorstellung der bis dahin fertigen Decisionsalle

Freitag, 29.01.2020 - Domain Exploration & Architectural Baseline

Beim Workshop am 29.1. konzentrieren wir uns auf die Festigung des Domain-Wissens und das Festlegen der wichtigsten Architektur-Eckdaten.

Zeit (ca.)InhaltWer
10:00 - 10:15

Offene Punkte, Ergänzungen Agenda für den Workshop

alle

10:15 - 11:00Bente
11:00 - 11:10

Grundlagen Domain Story Telling

Ruck, Uzun
11:10 - 11:45Session: Domain Story Tellingalle, Klein
11:45 - 12:00Fragen an Herrn Kleinalle, Klein
12:00 - 12:45SIGs: Arbeit an den Architecture DecisionsUntergruppen (SIGs), Discord
12:45 - 13:45Mittagspause
13:45 - 14:30SIGs: Arbeit an den Architecture DecisionsUntergruppen (SIGs), Discord
14:30 - 16:00

Vorstellung der bis dahin fertigen Decisions:

alle

Freitag, 05.02.2020 - API and Eventing

Beim Workshop am 05.02. legen wir die Grundlagen für die API-Spezifikation und -Implementation, dito für das Eventing.

Zeit (ca.)InhaltWer
10:00 - 11:00Fortsetzung Domain Story Telling (4 x 15min, abwechselnd Plenum / Untergruppen)Ruck, Uzun
11:00 - 11:30

Offene Punkte, Ergänzungen Agenda für den Workshop

  • Lauffähigkeit
    • Alle Teams mergen in Main
    • Alle Teams nutzen die Haupt-Applikation
  • Termin Abschlussveranstaltung
  • Stand der Implementation (pro Team)
  • Stand der Decisions
  • Fehlende Decisions

Bente, alle

11:30 - 12:30

UID: Neuer Stand des Wireframe / Fragen an Herrn Klein 

Klein, alle
12:30 - 13:30Mittagspause
13:30 - 14:00

Inhaltsimpulse:

  • Aggregates
  • REST APIs
Bente
14:00 - 15:15SIGs: Arbeit an den Architecture DecisionsUntergruppen (SIGs), Discord
15:15- 16:00

Vorstellung der fertigen Decisions

  • API Testing (+ Klassenstruktur)
  • API Documentation
  • Event Payload
  • Docker vs. VM
alle

Freitag, 12.02.2020 - State of the implementation

Beim Workshop am 12.02. schauen wir auf den Zustand der Implementation. 

Zeit (ca.)InhaltWer
10:00 - 10:15

Orga

  • Workshops: 19.2., Abschlusstag 2.3.
  • Präsentation 9.3.
  • offene Punkte
Bente, alle
10:15 - 11:00

Status der Unit Tests

APIs

  • Einheitliche URIs (siehe auch Issue)
    • teilweise nicht einmal Level 2
  • DTOs müssen zurückgegeben werden (siehe Decision, siehe Issue)
  • Level 3
    • es fehlt ein How-To für die Link-Generierung. Bitte bitte ergänzen Sie die API-Style-Decision und präsentieren noch einmal
    • Links generieren, siehe Issue (alle Teams)
    • Spezielle Klasse?
  • APIs sollten zumindest den vollen CRUD-Zyklus abdecken (siehe Issue)
  • API Documentation
    • Swagger Decision - bitte ergänzen Sie ein How-To und präsentieren heute noch einmal 
    • bitte alle Teams auf Swagger umstellen (siehe Issue)
  • API Authentication - Status der Decision?

Datenbank

Bente, alle
11:00 - 12:00

UID

  • Neuer Stand des Wireframe / Fragen an Herrn Klein
  • Was ist mit Variants? 
  • Linux Server?
  • Stand Domain Story Telling

Bente, alle

12:00 - 12:30

Eventing

  • Teams könnten ihre Spec teilen (alle außer Impact fertig?)
  • Implementieren (siehe Issue und Issue)

Code Quality

DevOps


12:30 - 13:30Mittagspause
13:30 - 15:15SIGs: Arbeit an den Architecture DecisionsUntergruppen (SIGs), Discord
14:30 - 15:30

Vorstellung der fertigen Decisions

  1. API testing decision mit How-To
  2. API-Style-Decision mit How-To
  3. Swagger Decision mit How-To
  4. Rational DB vs. NO-SQL DB
  5. DB Decision mit How-To
  6. Authentication Decision
  7. SonarLint and SonarCloud are used as code-quality tools
  8. Stand Build Pipeline? Application delivery - Tool Chain for Build Pipeline
alle
15:30 - 16:00

APIs und Events abgleichen

  • 4 Teams

Freitag, 19.02.2020 - Preparing the Finalisation of the FAE Project Phase

Beim Workshop am 12.02. planen wir, was bis wann noch im Rahmen dieser Veranstaltung zu geschehen hat, und was auf eine Roadmap für später gehört.

Zeit (ca.)InhaltWer
10:00 - 11:00

Aktuelle Probleme, Open Issues, Planung

  1. lokale Spring-Apps
    1. Maven-Modell (parent vs. nur Dependencies)
    2. war Workaround für die Zeit, wo die anderen Module nicht laufen
    3. werden anscheinend gebraucht, um die lokalen Tests laufen zu lassen (question)
    4. Optionen
      1. Module "auflösen", so dass es nicht mehr Module, nur noch Java-Packages sind; "package-private" als Option
      2. Spring-Konfiguration so lange recherchieren, bis wir die Lösung (Context auf Evatoolapp setzen)
      3. Spring-Konfigurationsdatei statt Application anlegen
  2. Swagger-Konfig
    1. => nach global verschieben
    2. Copy/Paste-Fehler mit der Version (=> sollte auf 2.6 gehen)
  3. Merge-Regeln
    1. Discord => ins Wiki
    2. Pre-Push-Hooks für Moment eher nicht
  4. Pattern zur Lösung der Global-Dependencies
    1. CDC
    2. Rabbit MQ
  5. Logger-Code
  • Absprache Präsentation am 9.3.
Bente, alle
11:00 - 11:30

UID: 

  • Neuer Stand des Wireframe / Fragen an Peter Klein
  • Server jetzt brauchbar?
  • Uhrzeit für Präsentation am 9.3. 
Klein, alle
11:30 - 14:00SIGs: Abschluss der Architecture Decisionsalle
14:00 - 16:00

Vorstellung 

  • alle SIGs: Decisions abschließend vorstellen
    • was ist mit den Todos, auch bei den "grünen" Decisions? 
  • alle Teams: Stand der Implementation und der Tests
alle

Abschlusstermin