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.

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. 

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: 

• Frei zugängliche Version des Fachartikels zu dem Tool: https://www.informatik-aktuell.de/management-und-recht/digitalisierung/mindsets-und-methoden-fuer-eine-praxisnahe-digitale-ethik.html
• Mitschnitt meines Vortrags auf der DigitalXChange 2020 zu dem Tool und dessen Hintergrund: https://www.youtube.com/watch?v=3OQzpUGqJnE (im Wesentlichen ein Teil meines OOP-Vortrags)
• In dem ILIAS-Ordner "Material UID" liegen erste Unterlagen von UID (Wireframes, Personas, Szenarien)
• Unter diesem Link finden Sie einen Wireframe von UID zu dem Tool: https://lsw4em.axshare.com/#id=wvfe6y&p=website
  • (ist ein Passwort drauf - das schreibe ich Ihnen noch auf einem anderen Kanal)

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: 

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.

Vorbereitung auf den Workshop

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

• Sehen Sie das Material zur Fallstudie an. 
• Schauen Sie sich bitte folgende Videos zu Domain-Driven Design an:
  • Entities und Value Objects
  • Warum unidirektionale Beziehungen im Logischen Datenmodell?
  • Eine kurze Einführung in Domain-Driven Design (DDD)
  • Design in Iterationen (als Grundprinzip des DDD)
  • Ubiquitous Language
  • DDD Building Blocks und Strategic Design
• Besorgen Sie sich mindestens die in der Literatur fettgedruckten Quellen. Essentiell ist das "blaue Buch" von Eric Evans und das "rote Buch" von Vaughn Vernon.
  • Recherchieren Sie darüber hinaus gern noch selbst weiter in Richtung DDD.
• Machen Sie sich mit dem Spring Framework vertraut, wenn noch nicht geschehen (Spring Data JPA, Spring Web MVC, ggfs. auch Spring Data REST)
• Stellen Sie sicher, dass Sie ein vernünftiges Dev Env auf Ihrem Rechner haben.
  • Wer nochmal ein Tutorial für die Basics haben möchte: http://staff.pages.st.archi-lab.io/st1/learning-material/ 
  • Git: am besten die Git Bash
  • IDE: hier bieten sich zwei Optionen an: 
    • IntelliJ Ultimate (frei für Studierende)
    • Visual Studio Code

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. 

Freitag, 22.01.2020 - Development Kickoff

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

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.

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.

Freitag, 12.02.2020 - State of the implementation

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

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.

Abschlusstermin