Architektur ist das, was man einführt und dann nicht mehr so leicht ändern kann, richtig? Also sollten Teams gut überlegen, welche Architekturmuster sie einsetzen und diese dann konsequent durchhalten. Mit dieser "rule of least surprise" lässt sich die Software gut weiterentwickeln.

Doch wie vereinbart man in einem selbstorganisierten Team nützliche Muster? Matthias zeigt an Beispielmustern und an Quellcode, wie Teams Architekturmuster für sich selbst definieren, die ihrer Plattform und ihren Skills angemessen und im Team breit akzeptiert sind.

Zielpublikum: Architekt:innen, Entwickler::innen
Voraussetzungen: Erfahrung in der Software-Entwicklung, erlittener Schmerz beim Lesen fremden Codes
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Was in einem Team gute Architektur ist, muss es für ein anderes Team noch lange nicht sein. Ich möchte Teams ermöglichen, gute Architektur-Ansätze auf dem Markt zu studieren und sie dann auf eigene Situation und Bedürfnisse anzupassen.

Als Beispiele bringe ich die 9 Standardbausteine aus dem Domain-Driven Design (Entity, Value Object, Service usw.), verbunden mit einer Ports&Adapters-Struktur (Port, Adapter, primary, secondary ...).

An sich sind diese Muster bewährt und gut – nur sollte man sie nicht einfach "irgendwie" realisieren oder 1:1 von einer Konferenz übernehmen, sondern auf die eigene Plattform- und Team-Situation abbilden und dazu einen Team-Beschluss herbeiführen.

Die Muster werden dann eher von allen getragen und eingehalten, was der Qualität sehr förderlich ist.