Domain Driven Design (DDD) ist eine Methodik zur Modellierung komplexer Software, die sich stark an der Fachlichkeit der jeweiligen Anwendungsdomäne orientiert und so die Trennung von Geschäftslogik und technischen Details fördert. DDD findet bisher in der Embedded-Entwicklung nur wenig Beachtung. Es eigne sich höchstens zum Entwurf komplexer Microservices-Architekturen und der Overhead sei durch zusätzliche Abstraktionsschichten zu groß. Genauer betrachtet sind viele Konzepte aus dem DDD auch für einen Embedded-Hersteller von großer Relevanz, besonders wenn dieser eine Produktplattform entwickelt.
Die Grundfrage jeder Architekturphilosophie ist, wie es gelingt Komplexität zu beherrschen und wiederverwendbare Softwarepakete zu erzeugen. Die Antwort des DDD ist, dass es dafür auf die richtige Organisationsstruktur und die Trennung von Produkt- und Domänenentwicklung ankommt. Conway’s Law“ besagt, dass Organisationen Systeme erzeugen, die sich an deren Kommunikationsstrukturen ausrichten. Strukturiert man seine Teams rein nach Produkten, wird man Softwarepakete bekommen, die gut technische Unterschiede abstrahieren, aber Geschäftsprozesse in den Hintergrund treten lassen. Strukturiert man seine Teams rein nach Prozessen in seiner Domäne, erhält man wiederverwendbare Geschäftslogik, die gegebenenfalls schwierig auf neue Technologien adaptierbar ist.
Mit dem Begriff „Architektur“ werden in der Softwareentwicklung oft technischen Aspekte, wie Layer, Frameworks oder Datenbanken, assoziiert. DDD nutzt daher den Begriff „strategisches Design“ um zu beschreiben, wie man große, komplexe Softwaresysteme fachlich – anhand von Geschäftsprozessen – strukturiert. Dazu wird die Domäne in sogenannte „Bounded Contexts“ zerlegt, die einen klar abgegrenzten Bereich der Geschäftslogik mit einem bestimmten Modell repräsentieren. Innerhalb eines Bounded Contexts gilt eine definierte „Ubiquitous Language“ die als gemeinsame Sprache die Grundlage der Kommunikation zwischen Entwicklern und Domänenexperten bildet. Die Sprache und auch das Modell richten sich rein an der Domäne aus und sind frei von technischen Umsetzungsdetails.
Strategisches Design hilft, Teams entlang fachlicher Grenzen zu organisieren. Jedes Team ist für einen oder mehrere Bounded Contexts verantwortlich – das fördert Autonomie und klare Zuständigkeiten. Abhängigkeiten zwischen Bounded Contexts, ihren Modellen und damit auch den Teams werden beim DDD explizit gemacht:
- Partnership: Teams arbeiten eng zusammen und entwickeln gemeinsam ein Modell.
- Shared Kernel: Teams teilen einen Teil des Modells (z. B. gemeinsame Bibliothek).
- Customer/Supplier: Das Customer-Team nutzt das Modell des Supplier Teams; Änderungen müssen abgestimmt werden.
- Conformist: Wie Customer/Supplier, jedoch ohne Abstimmung der Änderungen.
- Anticorruption Layer: Das Customer-Team nutzt ein fremdes Modell, aber kapselt dies in einem eigenen Adapter.
- Open Host Service: Team bietet standardisierte API an und supported diese für definierte Zeit.
- Published Language: Team bietet standardisierte Austauschformat an und supported dies für definierte Zeit.
- Separate Ways: Team erzeugen spezialisierte Lösungen in eigenen Bounded Contexts.
Die Konzepte aus dem DDD sind auch für Embedded-Hersteller interessant, sobald ihre Produkte und ihr Portfolio eine bestimmte Komplexitätsstufe erreichen und die Wiederverwendung von Software und die Aufteilung der Entwicklung in mehrere Teams ein Thema wird:
- Es zeigt alternative Möglichkeiten zur „offensichtlichen“ Strukturierung in Hardwareteams, Datenbankteams, Frontendteams, Feldbusteams und Produktteams auf. Bei einer solchen Aufteilung wird jedes Team seine eigene technologieorientierte Plattform erzeugen. Bei der Entwicklung eines neuen Features sind meistens alle Teams beteiligt und müssen aufeinander warten. Bei einer Aufteilung gemäß DDD könnte ein Team ein Feature vollständig unabhängig von den anderen entwickeln.
- Gerade Embedded-Software neigt dazu fachliche Logik mit direkten Hardwarezugriffen zu vermischen. Um eine Wiederverwendbarkeit zu erreichen, die einer Produktplattform genügt, führt jedoch kein Weg an der Trennung von Domänenlogik und Infrastruktur vorbei.
- DDD hilft die essentielle Komplexität der Domäne durch klare fachliche Modelle und Bounded Contexts zu strukturieren.
- Eine gemeinsame Sprache zwischen Entwicklern, Domänenexperten und Stakeholdern ist über den gesamten Produktlebenszyklus extrem vorteilhaft, denn Missverständnisse bei den Anforderungen sind besonders teuer.
- DDD lässt sich gut mit modellgetriebenen Ansätzen kombinieren, indem die Domänenmodelle als Grundlage für die Modellbildung verwendet werden.
- Viele Embedded-Systeme haben sehr lange Lebenszyklen. Dies erfordert eine Architektur, die auch nach Jahren noch verständlich, wartbar und erweiterbar ist. Hardware oder Frameworks werden in dieser Zeit abgekündigt werden und eine Migration erfordern. Mit den Konzepten des DDD ist man darauf bestmöglich vorbereitet.
In Zeiten von Industrie 4.0 möchten viele Hersteller Teile ihrer Applikationen in der Cloud oder als Digital Twin bereitstellen. Die DDD Konzepte helfen auch Szenarien zu unterstützen, bei denen SW-Komponenten sowohl in der Firmware als in der Cloud ausführbar sind. Man kann daher mit gutem Recht sagen, dass sie wohl für viele Embedded-Hersteller interessant sind.