Language
Country/Area
No result found
Warum die Konzentration auf Kernbereiche Ihr Entwicklungsprojekt retten kann? Hier sind die Wahrheiten, die Sie kennen müssen!
Da die Komplexität der Softwareentwicklung immer weiter zunimmt, werden die Herausforderungen für die Entwicklungsteams immer wichtiger. Unabhängig davon, ob die Zeit knapp ist oder sich die Anforderungen ändern, müssen Entwickler eine Lösung finden, um den Projektentwicklungsprozess effizienter zu gestalten. Mittlerweile ist Domain Driven Design (DDD) eine beliebte Strategie.
„Die Konzentration auf Kernbereiche ist keine Wahl, sondern eine Notwendigkeit.“
Das wichtigste Konzept des domänengesteuerten Designs besteht darin, das Softwaremodell effektiv mit der Geschäftsdomäne zu verbinden. Durch ausführliche Gespräche mit Experten auf diesem Gebiet können Entwickler die Geschäftslogik verstehen und Softwaresysteme erstellen, die nicht nur die Benutzeranforderungen erfüllen, sondern auch kontinuierlich gewartet werden können. Der Schlüssel bei diesem Ansatz liegt darin, sich auf Kernbereiche zu konzentrieren, anstatt zu versuchen, alle Probleme auf einmal zu lösen.
Durch domänengesteuertes Design können wir große Systeme in mehrere „begrenzte Kontexte“ aufteilen, von denen jeder sein eigenes unabhängiges Modell hat. Eine solche Aufteilung hilft den Entwicklungsteams, sich auf bestimmte Funktionsbereiche zu konzentrieren und reduziert abteilungsübergreifende Störungen. Gleichzeitig wird dadurch auch die kreative Zusammenarbeit zwischen Fachexperten und Entwicklern gefördert und eine iterative Überarbeitung von Konzeptmodellen ermöglicht.
„Das Design des Modells muss den geschäftlichen Anforderungen entsprechen. Nur so bleibt das System leicht zu warten.“
Ein weiterer Vorteil des domänengesteuerten Designs besteht darin, dass es die Bedeutung einer einheitlichen Sprache unterstreicht. Bei der sogenannten Ubiquitous Language handelt es sich um eine von Fachexperten, Anwendern und Entwicklern genutzte Sprache, die dazu beitragen kann, dass alle Beteiligten ein klares Verständnis der Geschäftsanforderungen haben. Da alle im gleichen Kontext kommunizieren, können Kommunikationsfehler effektiv reduziert und der Projektfortschritt gefördert werden.
Kritiker weisen jedoch darauf hin, dass die Implementierung von DDD im Hinblick auf die Reinheit und Nützlichkeit des Modells viel Isolierungs- und Kapselungsarbeit erfordert. Dies bedeutet, dass Entwickler ständig die Konsistenz innerhalb der Modellgrenzen aufrechterhalten müssen und zukünftige Änderungen als zusätzliche Belastung betrachten. Insbesondere bei kleineren oder weniger komplexen Projekten kann dieser Ansatz zu unnötigem Mehraufwand führen. Daher empfiehlt Microsoft die Einführung von DDD nur in komplexen Bereichen, in denen es sich lohnt, wenn das Modell eindeutig ein gemeinsames Geschäftsverständnis vermittelt.
Über Modelltypen
DDD erkennt, dass es mehrere Modelle gibt, von denen die gängigsten Entitäten und Wertobjekte umfassen. Eine Entität ist ein Objekt, das durch seine Identität definiert ist, während ein Wertobjekt durch seine Attribute definiert ist und keine konzeptionelle Identität hat. Die meisten Fluggesellschaften weisen beispielsweise jedem Sitzplatz in einem Flugzeug eine eindeutige Nummer zu, die die Identität des Sitzplatzes angibt. Im Gegensatz dazu achten Menschen beim Austausch von Visitenkarten mehr auf die Informationen auf den Karten und nicht besonders auf die Einzigartigkeit jeder einzelnen Karte.
„Das Verständnis unterschiedlicher Modelltypen ist der Grundstein zur Beherrschung von DDD.“
Mit dem Modell interagieren
Bei DDD ist der Prozess der Objekterstellung häufig vom Objekt selbst getrennt. Ein Repository ist beispielsweise ein Objekt, das über Methoden zum Abrufen von Domänenobjekten aus einem Datenspeicher wie einer Datenbank verfügt. Die Factory wird zum direkten Erstellen von Domänenobjekten verwendet. Darüber hinaus kann ein Teil der Programmfunktionalität, der konzeptionell zu keinem Objekt gehört, normalerweise durch einen Dienst ausgedrückt werden.
Ereignistyp
In DDD können Ereignisse in mehrere Typen unterteilt werden, die wichtigsten davon sind „Domänenereignisse“ und „Integrationsereignisse“. Domänenereignisse signalisieren wichtige Vorkommnisse innerhalb einer bestimmten Geschäftsdomäne, während Integrationsereignisse dazu dienen, Änderungen zwischen verschiedenen Randkontexten zu kommunizieren. Beide spielen eine entscheidende Rolle bei der Gewährleistung der Systemdatenkonsistenz und der Integrität der Geschäftslogik.
Kontextzuordnungsmodus
Kontextmapping ist von entscheidender Bedeutung für die Identifizierung und Definition der Grenzen verschiedener Domänen oder Unterdomänen. Es hilft dabei, die Interaktion und die Beziehungen dieser Kontexte zu visualisieren. Dadurch werden klare Grenzen gewahrt und die Kopplung reduziert.
Beziehung von Domain Driven Design zu anderen Ideen
Obwohl domänengesteuertes Design nicht unbedingt Hand in Hand mit objektorientierten Methoden geht, ergänzt es in der Praxis die Stärken dieser Techniken. Im Unterschied zur traditionellen Architektur konzentriert sich DDD eher auf das Geschäftsverhalten als auf ein bestimmtes technisches Framework.
ZusammenfassungOb durch Methoden wie Event Storming, Event Sourcing oder durch die Zuordnung begrenzter Kontexte zu Microservices – DDD bietet eine Reihe von Tools und Methoden, die Entwicklern dabei helfen, Geschäftsanforderungen zu verstehen und umzusetzen. Durch die Konzentration auf die Kernbereiche erhöht sich letztlich nicht nur die Wahrscheinlichkeit eines Projekterfolgs, sondern auch die zukünftigen Wartungskosten werden effektiv gesenkt. Haben Sie in diesem Zusammenhang auch schon darüber nachgedacht, welche Veränderungen eine Konzentration auf Ihre Kernbereiche für Ihre Entwicklungsprojekte mit sich bringen kann?
