Themenspeicher für

Certified Professional for
Software Architecture^®
Expert Level

Software Projekte werden mit der Zeit in der Regel zäher, zerbrechlicher und fehleranfälliger. Der Grund liegt oft in zu vielen Abhängigkeiten, schlechter Kohäsion und hoher Kopplung. Domain-Driven Design (DDD) verspricht hier Abhilfe.

DDD ist aber mehr als nur das Schneiden von Komponenten. Vieles davon wird oft übersehen, wodurch viele seiner Stärken nicht ausgenutzt werden können: Deep Insight, Break Through, Supple Design, Large Structures.

Außerdem ist DDD ein sehr agiler Ansatz, der bei richtiger Umsetzung starken Einfluss auf Arbeitsabläufe und Firmenstrukturen hat.

Durch die Bearbeitung des Themas soll gezeigt werden, welche Probleme mit DDD gelöst und was mit DDD erreicht werden kann.

Ebenso sollen aber auch die Auswirkungen aufs Unternehmen gezeigt werden, oder warum DDD scheitern kann. Welche Voraussetzungen müssen gegeben sein, damit DDD seinen Nutzen bringt?

Das Thema soll u. a. aus Sicht einer Organisation, des Managements, der Software-Entwickler und der Anwender beleuchtet werden.

Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Pearson ITP.

Vernon, V. (2013). Implementing Domain-Driven Design. Pearson ITP.

Das Thema sollte von einer Gruppe mit 3-5 Personen bearbeitet werden.

Dokumentation ist in der Softwareentwicklung genauso wichtig wie unbeliebt. In der Vergangenheit und unter Einfluss des Wasserfallmodells entstanden oft unübersichtliche Papierwüsten. In der agilen Softwareentwicklung hingegen wird Dokumentation oft als Ballast und überflüssig angesehen. Neue Medien und das Erkennen der Wichtigkeit für eine saubere Architekturdokumentation werfen ein neues Licht auf die Dokumentation.

Was sind Qualitätsmerkmale für eine gute Dokumentation der Architektur und wie führt man diese Erkenntnisse in ein Projekt ein? Welche Erfahrungen mit der Einführung und dem täglichen Gebrauch können an andere Teams weitergegeben werden? Welche Schwierigkeiten traten auf und wie wurde damit umgegangen. An welchen Stellen gibt es noch ungelöste Fragen und Probleme?

Folgende Fragen sollen behandelt werden:

Zörner, S. (2021). Software-Architekturen dokumentieren und kommunizieren. Hanser Verlag

Starke, G. & Hruschka P. (2022). Arc42 in Aktion: Praktische Tipps zur Architekturdokumentation. Carl Hanser Verlag

Homepage of the ADR GitHub organization. https://adr.github.io/

Brown, S. The C4 model for visualising software architecture. https://c4model.com/

Das Thema sollte von einer Gruppe mit 3-6 Personen bearbeitet werden.

NoSQL-Datenbanken sind längst kein Novum mehr. In vielen Projekten sind sie Standard, in vielen aber auch nicht.

Wer bislang nur mit relationalen Datenbanken zu tun hatte, kann sich oft nicht vorstellen, wie der Einsatz von NoSQL-Datenbanken gelingen kann:

Das Thema ist interessant für Architekten, Entwicklung, Betrieb, DB-Administratoren

Es sollen diese Fragen beantwortet werden:

Weitere Themen in diesem Zusammenhang sind Event Sourcing, Eventually Consistency, Skalierbarkeit, Ausfallsicherheit, Lizenzen oder BASE

Ein paar gelungene Beispiele aus der Praxis mit Tipps und Tricks würden weiterhelfen.

Fowler, M., & Sadalage, P. J. (2012). NoSQL distilled. Pearson Education.

Das Thema sollte von einer Gruppe mit 3-5 Personen bearbeitet werden.

Nicht erst seit der Veröffentlichung von Vernons Buch „Implementing Domain-Driven Design“ mit dem Vorwort von Eric Evans sind Event-Driven Architekturen von Interesse. Event-Driven Architekturen (EDA) bieten ein hohes Maß an Flexibilität in der Software. Sei es im Programmablauf oder in der Datenerfassung. EDAs werden in vielen Orten bereits erfolgreich eingesetzt. Auch Cloud Provider bieten Lösungen an. Immer mehr Frameworks kommen hierzu auf den Markt. Monitoring, BI und viele weitere Bereiche machen von EDAs Gebrauch.

Event-Driven Architekturen helfen dabei, flexible Systeme zu schaffen, die sich an Veränderungen anpassen und Entscheidungen in Echtzeit treffen können. Ereignisse werden erfasst, sobald sie von Ereignisquellen wie Internet-of-Things-Geräten (IoT), Anwendungen und Netzwerken eintreten, sodass Event-Produzenten und Event-Consumer Status- und Reaktionsinformationen in Echtzeit austauschen können. In diesem Kontext wird auch häufig über die Konzepte des Event Sourcings und CQRS gesprochen, die weitere Herausforderungen bieten, aber auch spannende Vorteile versprechen.

Diese Fragen sollen behandelt werden:

Vernon, V. (2013). Implementing Domain-Driven Design. Pearson ITP.

Domogalla, M. (2022, April 21). Software-Architektur.tv: Softwarearchitektur MIT events, event sourcing UND CQRS. Developer. https://www.heise.de/news/software-architektur-tv-Softwarearchitektur-mit-Events-Event-Sourcing-und-CQRS-7061126.html

Das Thema sollte von einer Gruppe mit 3 bis 7 Personen bearbeitet werden.

Große Softwaresysteme werden in der Regel von mehreren Entwicklungsteams umgesetzt. Während sich im Backend Feature-Teams durchgesetzt haben, wird in vielen Projekten das Frontend von einem einzigen Team entwickelt. Doch auch im Frontend setzt sich immer mehr der Microservice-Gedanke durch: Unabhängige Teams arbeiten an einem fachlichen Frontend-Baustein und können ihren Baustein unabhängig von den anderen Teams entwickeln und ausliefern. Für die Umsetzung dieser sogenannten Microfrontend-Architektur gibt es verschiedenste methodische und technische Ansätze.

Folgende Fragen sollen beantwortet werden:

Das Thema sollte von einer Gruppe mit 3 bis 5 Personen bearbeitet werden.

Maschinelles Lernen (ML) entwickelt sich immer mehr von einer Fiktion zu einer nicht mehr wegzudenkender Technik. Wer sich nicht früh mit ML beschäftigt, für den kann der Zug später vielleicht schon abgefahren sein. Dennoch ist ein Investment sehr riskant.

Einsatzgebiete sind sehr vielfältig: Baubranche, Automobilindustrie, Finanzwesen, Behörden, Logistik, Marketing. Die Umsetzung erfordert allerdings neue Talente, und wirft Fragen auf. Niemand sollte diese Entwicklung verschlafen.

Im Rahmen der Digitalisierung oder der stärker werdenden Konkurrenz braucht es neue Lösungen, bei denen ML eine gute Hilfe anbieten kann. Im Bereich von Business Intelligence oder Big Data braucht es neue Verfahren, bei denen ML unterstützen kann.

Der Beitrag soll Mut machen, einen Einstieg in dieses Thema zu finden.

Es gibt viele Dinge zu klären:

Das Thema sollte von einer Gruppe mit 3-7 Personen bearbeiten werden.

Märkte werden komplexer, Software, wird im Bereich Business und Technologie komplizierter. Das nötigt Firmen immer häufiger dazu, die Lösung für ihre SW-Projekte in einer Microservices-Architektur (µService) zu suchen.

µServices werden in der Regel mit Kubernetes (K8s) realisiert. Kubernetes ist ein hoch kompliziertes und komplexes Framework. Entwickler sind mit deren Installation, Nutzung und Betrieb häufig überfordert. Projekte können so leicht scheitern oder unrentabel werden. Ein intensiver Austausch zwischen den Rollen Anforderungsmanagement, Architektur, Entwicklung, Test und Betrieb ist deshalb erforderlich. Fehlende Agilität und starre Strukturen im Unternehmen kommen erschwerend hinzu. Erste Ansätze gibt es dafür im DevOps. Weitere werden nötig.

Die Teilnehmer sollen die Probleme, Herangehensweise und Lösungen aus ihren Projekten aufarbeiten und einen Leitfaden erstellen.

Liebel, O. (2023). Skalierbare Container-Infrastrukturen: Das Handbuch für Administratoren (4. Ausgabe). Rheinwerk Computing.

Das Thema soll von einer Gruppe mit 6-7 Personen bearbeiten.

Seit über 20 Jahren gilt UML als der Standard für die Modellierung von Software-Systemen. Andere Modellierungssprachen positionieren sich entweder als leichtgewichtige Alternativen (z. B. C4), als vollständigen Ersatz oder für einen bestimmten Anwendungsbereich bzw. Domäne (z. B. BPMN, SysML, ArchiMate).

Die Verwendung von Modellierungssprachen ist nicht immer beliebt. Sie werden oft als zu kompliziert oder aufwändig angesehen. Dennoch lassen sich große Projekte ohne Modellierung nicht umsetzen. Zu spät wird oft erkannt, dass man die Zusammenhänge im Projekt nicht mehr durchschaut und ein geeignetes Modell hier hätte helfen können. Noch besser wäre es gewesen, schon beizeiten mit der Modellierung zu beginnen, um die Kommunikation im Projekt zu fördern.

Die Themenarbeitsgruppe soll folgende Fragen diskutieren und die Erkenntnisse aufbereiten:

Das Thema sollte von einer Gruppe mit 4-7 Personen bearbeitet werden.

In den letzten Jahren gab es vermehrt Stimmen, die behaupteten, dass die SOLID-Prinzipien nicht mehr zeitgemäß wären. So sorgte etwa 2021 Dan North für Aufregung, als er behauptete, jedes einzelne SOLID-Prinzip wäre falsch. Nach etwas Zeit legte er nach und schlug als Alternative seine sogenannten „CUPID-Properties“ vor:

Die Themenarbeitsgruppe soll folgende Fragen klären:

Das Thema soll von einer Gruppe mit 3-5 Personen bearbeiten werden.