Entwurf von Architekturen für eng gekoppelte Domänen

Es gibt zahlreiche Muster, Tipps und Konzepte, die sich damit befassen, wie man eine Architektur für ein System unter Verwendung von DDD, Clean/Onion/Hexagonal/ereignisgesteuerten Architekturen, CQRS, Microservices und vielem mehr entwirft. All diese Ansätze legen den Schwerpunkt auf die Zerlegung und Trennung von Anliegen.
Doch wie lassen sie sich auf eine sehr eng gekoppelte Domäne anwenden? Eine eng gekoppelte Domäne weist Abhängigkeiten zwischen Geschäftsregeln, Datenverflechtungen und Invarianten über natürliche Grenzen hinweg auf. Alles hängt irgendwie miteinander zusammen.

In diesem Vortrag werde ich darüber berichten, was wir in über 11 Jahren beim Aufbau eines Systems mit einem eng gekoppelten Domänenbereich gelernt haben: Welche Muster und Konzepte sind nach wie vor sinnvoll, welche nicht, wie wir einige davon angepasst haben, damit sie besser zu unserem Domänenbereich passen, und welche zusätzlichen Erkenntnisse wir gewonnen haben, wie zum Beispiel fraktale Schnitte.
Nachdem ich erläutert habe, was eine eng gekoppelte Domäne so besonders macht, werst du verstehen, warum Modularisierung nach wie vor wichtig ist, warum sich die Kommunikation zwischen diesen Teilen unterscheidet und welche Konsequenzen dies für die Architektur hat.

Wenn du in Vorträgen zur Softwarearchitektur schon genug Webshop-Domains gesehen hast, ist dieser Vortrag genau das Richtige für dich.

Onion, Hexagonal, Clean or Fractal Architecture? Alle, und noch mehr!

Onion-, Hexagonal, Clean oder Fractal Architekturen zielen darauf ab, den Umgang mit Abhängigkeiten in unseren Software-Architekturen zu organisieren. Aber welche sollten wir wählen?

Zuerst arbeite ich die Essenz jedes Ansatzes heraus und zeige die Vorteile und Herausforderungen. Anschliessend kombiniere ich die Konzepte, um in evolutionären Schritten zu einer Architektur zu gelangen, die vom ersten Tag an bis zum Ableben der Software deinen Bedürfnissen entspricht . Mit konkreten Beispielen aus unserer über zehnjährigen real-world Applikation.

Du wirst sehen, dass Layers und Slices nicht ausreichen. Eine Modularisierung, die zur Domäne passt und die Verständlichkeit, Änderbarkeit und Erweiterbarkeit vereinfacht, muss über diese Konzepte hinausgehen.

From User Stories to Architecture

Wenn Teams neu mit agiler Softwareentwicklung starten, kämpfen diese oft mit der Einbettung der Architektur in die inkrementelle und iterativen Vorgehensweise. Unklare und sich häufig ändernde Anforderungen stellen neue Ansprüche an die Erstellung der Architektur. Das Resultat ist meist ein inkonsistentes und schlecht wartbares Software System. Urs Enzler zeigt Ihnen wie Sie die Architektur Feature für Feature entstehen lassen und welche Vorteile Sie gegenüber einem Big-Design-Up-Front Vorgehen erhalten.