Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Domain Driven Design - Stabile Basis für langlebige Software

61 Aufrufe

Veröffentlicht am

Digitale Geschäftsmodelle, digitale Produkte, Digitalisierung: IT hat heutzutage einen Stellenwert in der Geschäftswelt wie kaum zuvor. Welche Möglichkeiten bietet modernes Softwareengineering, damit Softwarelösungen in Sachen Innovation, Geschwindigkeit und Passgenauigkeit bei gleichzeitig hoher Stabilität und Anpassungsfähigkeit den mit der Digitalisierung verbundenen Erwartungen gerecht werden können? Und welche Anforderungen ergeben sich daraus für IT-Abteilungen?

Auf diese Herausforderungen gaben die Referenten auf dem IKS-Thementag "Softwareengineering heute" antworten aus 3 Themenbereichen:

- Von der Idee zur Lösung in Rekordzeit: Anforderungsmanagement und Qualitätssicherung in agilen Projekten
- Domain Driven Design: Stabile Basis für langlebige Software
- Design Thinking: Innovative Konzepte für erfolgreiche Softwarelösungen

Weitere Vorträge, die wir auch gern in Ihrem Unternehmen halten, finden Sie unter: https://www.iks-gmbh.com/impulsvortraege

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Domain Driven Design - Stabile Basis für langlebige Software

  1. 1. Domain Driven Design - Stabile Basis für langlebige Software 1 | 52 Projekte. Beratung. Spezialisten. Domain Driven Design IKS-Thementag „Softwareengineering heute“ 21.06.2018 Autor: Christoph Schmidt-Casdorff Stabile Basis für langlebige Software
  2. 2. Domain Driven Design - Stabile Basis für langlebige Software 2 | 52 Agenda Warum Domain Driven Design ? Strategisches Design - Konzepte im Problemraum Strategisches Design - Konzepte im Lösungsraum Taktisches Design und Architektur Essentials Abschluss
  3. 3. Domain Driven Design - Stabile Basis für langlebige Software 3 | 52 Agenda Warum Domain Driven Design ? Strategisches Design - Konzepte im Problemraum Strategisches Design - Konzepte im Lösungsraum Taktisches Design und Architektur Essentials Abschluss Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  4. 4. Domain Driven Design - Stabile Basis für langlebige Software 4 | 52 Warum Domain Driven Design? Software soll Geschäftsanforderungen lösen => Fokus auf die Fachlichkeit Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  5. 5. Domain Driven Design - Stabile Basis für langlebige Software 5 | 52 Fokus auf die Fachlichkeit Software dient zur Umsetzung von Geschäftsanforderungen  Nicht umgekehrt Fachlichkeit ist langlebiger als Technologien  Fachlichkeit bringt Stabilität in Software Fachlichkeit ist der gemeinsame Nenner  . . . aller am Entwicklungsprozess Beteiligten Domänenwissen begleitet die Softwareentwicklung  Softwareentwicklung startet und endet mit dem Wissen der Domänen-Experten Domäne ist das Problemfeld, für das eine Lösung gefunden werden soll Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  6. 6. Domain Driven Design - Stabile Basis für langlebige Software 6 | 52 Fachlichkeit im Zentrum der Softwareentwicklung Problemraum Lösungsraum Code Architektur Fachliche Kriterien bestimmen das Vorgehen Allgemeingültige Sprache Fachliche Durchgängigkeit Destillation Strategisches Design Taktisches Design Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  7. 7. Domain Driven Design - Stabile Basis für langlebige Software 7 | 52 Ziele von Domain Driven Design Domain Driven Design beschreibt einen Prozess Domain Driven Design gibt Verfahren/Techniken unterstützend an die Hand Domain Driven Design ist eine Denkungsart/Philosophie  Beschreibt Grundsätze zur Ausrichtung einer Softwareentwicklung an der Fachlichkeit Fachlichkeit steht im Zentrum der Softwareentwicklung  Design ist isoliert von Technologie  Über Technologie wird immer nachrangig entschieden  Auf das Verständnis der Fachlichkeit wird viel Energie verwendet Design und Software spiegeln die Fachlichkeit wieder  Nachvollziehbar  Methodisch Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  8. 8. Domain Driven Design - Stabile Basis für langlebige Software 8 | 52 Domain Driven Design – Was ist anders/besser? Fachlichkeit und Software korrespondieren nachvollziehbar  Dies ist durch die Methode vorgegeben  In welchem Softwarebaustein ist diese Fachlichkeit umgesetzt?  Für welche Fachlichkeit ist dieser Baustein zuständig? Softwarelösung skaliert mit der Komplexität  Integration einer fachlichen Änderungen darf nicht mit der Größe/Komplexität des Systems komplizierter werden  Wachsende Komplexität bleibt wartbar Zusammenarbeit steht im Mittelpunkt  Fachexperten und Entwicklung arbeiten Hand in Hand  Fachexperten und Entwicklung kommunizieren technologiefrei  Zusammenarbeit verstärkt und vereint unterschiedliche Fähigkeiten Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  9. 9. Domain Driven Design - Stabile Basis für langlebige Software 9 | 52 Worum geht es bei Domain Driven Design? Es geht um Sprache Es geht um Zusammenarbeit Es geht um Methoden und Verfahren Es geht um eine Änderung von Denkmustern Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  10. 10. Domain Driven Design - Stabile Basis für langlebige Software 10 | 52 Agenda Warum Domain Driven Design ? Strategisches Design - Konzepte im Problemraum Strategisches Design - Konzepte im Lösungsraum Taktisches Design und Architektur Essentials Abschluss Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  11. 11. Domain Driven Design - Stabile Basis für langlebige Software 11 | 52 Fachlichkeit im Zentrum der Softwareentwicklung Lösungsraum Code Architektur Allgemeingültige Sprache Fachliche Dekomposition Problemraum Destillation Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  12. 12. Domain Driven Design - Stabile Basis für langlebige Software 12 | 52 Gemeinsames Verständnis ist alles Gemeinsame Sprache ist Schlüssel zum gemeinsamen Verständnis  Eine gemeinsames Verständnis zu entwickeln ist mühselig aber notwendig  Klärung der fachlichen Begriffe Klarheit der gemeinsamen Sprache ist Indikator für die Tiefe des Verständnis  Unklare Begrifflichkeit deutet auf tieferliegende, verdeckte Konzepte hin  Mache Implizites Explizit Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  13. 13. Domain Driven Design - Stabile Basis für langlebige Software 13 | 52 Gemeinsame Sprache ist alles Gemeinsames Verständnis durch gemeinsam entwickelte Sprache  Ubiquitous Language  Eindeutige Bedeutung innerhalb der Ubiquitous Language Ubiquitär = „allumfassend, überall vorhanden, allgegenwärtig“  Jeder im Projekt muss die Sprache sprechen und verstehen können  Alle relevanten Sachverhalte müssen sich durch die Sprache beschreiben lassen  Die Sprache ist in allen Phasen der Entwicklung präsent  Die Sprache lebt Die gemeinsame Sprache ist eines der wichtigsten Konzepte in DDD  Grundlage für gemeinsames Verständnis  Grundlage für durchgängiges Verständnis  Indikator für Durchdringung und Stabilität (der Beschreibung) der Domäne Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  14. 14. Domain Driven Design - Stabile Basis für langlebige Software 14 | 52 Ubiquitäre Sprache Ubiquitäre Sprache entsteht während der Modellierung  Initial während der Analyse des Problembereichs  Lebt während aller Phasen der Softwareentwicklung Ubiquitäre Sprache muss explizit aufgeschrieben und gepflegt werden  Z.B. Wiki Ubiquitäre Sprache gehört zur Welt der Entwicklung wie auch der Domäne  Klärung der unterschiedlichen Sichten/Konzepte zwischen Fachexperten und Entwicklung Ubiquitäre Sprache durchdringt alle Phasen und Artefakte  … wird durchgängig genutzt  auch in Code, Tests,…  Ubiquitäre Sprache ist daher deutlich mehr als ein Glossar Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  15. 15. Domain Driven Design - Stabile Basis für langlebige Software 15 | 52 Domain Driven Design – Problemraum Problemraum Experten & Entwicklung Verständnis der Domäne erarbeiten sich Ubiquitäre Sprache Sprache der Domäne Vokabular Nach Practicing Domain-Driven Design , Millet, Leanpub Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  16. 16. Domain Driven Design - Stabile Basis für langlebige Software 16 | 52 Dekomposition des Problemraums Teile und Herrsche  Problembereich wird in abgeschlossene, kohärente, logische Sub-Domain aufgeteilt  Nach fachlichen Kriterien  Klare fachliche Zuordnung  Eine fachliche Quelle / ein fachlicher Treiber  Klare Abgrenzung einer Domäne … drückt sich durch die ubiquitäre Sprache aus  Erkenntnisse während der Dekomposition beeinflussen die ubiquitäre Sprache … ist im Fluss  Eine gewisse Stabilität ist Voraussetzung für die nächsten Schritte … entsteht kooperativ, übergreifend, iterativ  DDD stellt Verfahren/Techniken zur Unterstützung der Dekomposition bereit  Insbesondere Methoden um Core Domain zu finden Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende DDD-Bezeichnung für die Partitionen im Problemraums
  17. 17. Domain Driven Design - Stabile Basis für langlebige Software 17 | 52 Dekomposition des Problemraums ... orientiert sich an business capabilities … kann zugeordnete Geschäftsobjekte besitzen … kann Bezug zu Geschäftsvorgängen besitzen Bewertet Subdomains nach Relevanz für mein System  Bewertung nach Kritikalität/Wichtigkeit für die Geschäftsanwendung  Destillation (Literaturbegriff : distillation) Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende (Fachliche) Kompetenzen, um Geschäftsziele zu erreichen
  18. 18. Domain Driven Design - Stabile Basis für langlebige Software 18 | 52 Prioritäten nach fachlichem Mehrwert Core Domain Supporting Domains Generic Domain FachlicherMehrwert Investition Strategisch wesentlich Erfolgsfaktor Spezialisiertes Fachwissen Alleinstellungsmerkmal (Sehr) proprietär Tiefergehendes Design (tactical design) Erfahrene Entwickler Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  19. 19. Domain Driven Design - Stabile Basis für langlebige Software 19 | 52 Domain Driven Design | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen Domain Driven Design – Problemraum Problemraum Fachexperten & Entwicklung Supporting Domains Core Domains Generic Domain Verständnis der Domäne erarbeiten sich Ubiquitäre Sprache Sprache der Domäne Vokabular Domäne Nach Practicing Domain Driven Design , Millet, Leanpub Domain Vision Statement legt offen Highlighted Core legt offen bleiben synchron
  20. 20. Domain Driven Design - Stabile Basis für langlebige Software 20 | 52 Wie werden die Ziele der Dekomposition erreicht? Experten und Entwicklung arbeiten zusammen  kooperativ  kommunikativ DDD ist ein andauernder Lernprozess über die Fachlichkeit  iterativ  explorativ  Kompetenzgewinn spiegelt sich in Ergebnissen wieder Sprache treibt und bestimmt das Vorgehen  Ubiquitäre Sprache beschreibt das gemeinsame Verständnis der Domäne  Ubiquitäre Sprache bestimmt die Dekomposition (Destillation) Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  21. 21. Domain Driven Design - Stabile Basis für langlebige Software 21 | 52 Agenda Warum Domain Driven Design ? Strategisches Design - Konzepte im Problemraum Strategisches Design - Konzepte im Lösungsraum Taktisches Design und Architektur Essentials Abschluss Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  22. 22. Domain Driven Design - Stabile Basis für langlebige Software 22 | 52 Fachlichkeit im Zentrum der Softwareentwicklung Lösungsraum Fachliche Kriterien bestimmen das strategische Design Problemraum Code Architektur Begriffe und sprachlicher Kontext Kollaboration Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  23. 23. Domain Driven Design - Stabile Basis für langlebige Software 23 | 52 Überführe das WAS in das WIE - Lösungsraum Schritt 1: Überführe Sub-Domains in den Lösungsraum  Bounded Context Schritt 2 : Beschreibe die Zusammenarbeit der einzelnen Bounded Contexts  Context Mapping (of Bounded Contexts) Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  24. 24. Domain Driven Design - Stabile Basis für langlebige Software 24 | 52 Bedeutung und sprachlicher Kontext Wo kommt Mehrdeutigkeit von Begriffen her? Begriffe leben in unterschiedlichen sprachlichen Kontexten  Haben dort unterschiedliche Bedeutung  Klassiker: Auftrag, Kunde, Stammdaten, Person, Bestellung, Produkt, Buch Bedeutung ist immer auf einen (sprachlichen) Kontext bezogen  Dieser Kontext ist in der gemeinsamen Sprache festzuhalten DDD fördert explizit unterschiedliche sprachliche Kontexte  Diese bleiben getrennt, werden nicht vereinheitlicht Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  25. 25. Domain Driven Design - Stabile Basis für langlebige Software 25 | 52 Beispiel für einen sprachlichen Kontext Buchbestellung Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  26. 26. Domain Driven Design - Stabile Basis für langlebige Software 26 | 52 Buchbestellung Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  27. 27. Domain Driven Design - Stabile Basis für langlebige Software 27 | 52 Das Buch in unterschiedlichen Kontexten bestellen Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  28. 28. Domain Driven Design - Stabile Basis für langlebige Software 28 | 52 Buch - Unternehmensmodell Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  29. 29. Domain Driven Design - Stabile Basis für langlebige Software 29 | 52 Buch in unterschiedlichen Kontexten Das Konzept Buch wird auf die einzelnen Bounded Contexts verteilt  Es hat in jedem Kontext eine unterschiedliche Bedeutung  ISBN13 hält alle Ausprägungen zusammen Buch kann sich in jedem Kontext unabhängig weiterentwickeln Dieses Verständnis benötigt unabdingbar die ubiquitäre Sprache  Bounded Context als sprachlicher Kontext Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  30. 30. Domain Driven Design - Stabile Basis für langlebige Software 30 | 52 Bounded Context (1) Bounded Context repräsentiert Sub-Domänen im Lösungsraum  Faustregel : Eine Sub-Domäne wird zu einem Bounded Context  Bounded Contexts tragen Rahmenbedingungen Rechnung Bounded Context ist ein eigener sprachlicher Kontext  Begriffe bezüglich des Kontexts können in einem anderen Kontext eine andere Bedeutung haben Bounded Context repräsentiert fachlich unabhängige Bereiche  abgeleitet aus Sub-Domains Bounded Context hat explizit formulierte Grenzen  Bounded Contexts kommunizieren (nur) über öffentliche Schnittstellen Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  31. 31. Domain Driven Design - Stabile Basis für langlebige Software 31 | 52 Bounded Context (2) Bounded Context ist (weitestgehend) unabhängig  Das Konzept der unabhängigen Sprachkontexte forciert Autonomie  Autonomie ist der Schlüssel zur Beherrschung von langlebigen Systemen Bounded Context ist kohärent  So kompakt wie möglich  So umfangreich wie notwendig  Faustregel: Bounded Context orientiert sich an einem Aggregate Bounded Context wird durch ein Team entwickelt  Domänenexperten, Entwickler, Test, … Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  32. 32. Domain Driven Design - Stabile Basis für langlebige Software 32 | 52 Autonomie, Autonomie, Autonomie …. Autonomie, um … … fachliche Entscheidungen innerhalb eines Bounded Context zu treffen … Auswirkungen des (Daten-)modells auf Bounded Context zu beschränken  Kleine lokale Datenmodelle versus Unternehmensmodell Domain Driven Design | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen
  33. 33. Domain Driven Design - Stabile Basis für langlebige Software 33 | 52 Context Mapping und Collaboration Pattern DDD dokumentiert die Beziehung der Bounded Contexts Context Mapping DDD beschreibt Muster und Klassifizierung der Zusammenarbeit Collaboration Pattern Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  34. 34. Domain Driven Design - Stabile Basis für langlebige Software 34 | 52 Überblick behalten - Context Map Dokumentation, wie die einzelnen Bounded Contexts zusammenspielen  Wer konsumiert wen?  Bietet Überblick über die Landschaft der Bounded Contexts. Context Map klärt die Beziehung zwischen Bounded Contexts und Teams  Welches Team zu welchem Bounded Context? Context Map beschreibt Kommunikationsmuster  In welcher Form kooperieren die Teams?  DDD beschreibt Muster der Zusammenarbeit: Collaboration Patterns Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  35. 35. Domain Driven Design - Stabile Basis für langlebige Software 35 | 52 Domain Driven Design - Lösungsraum Nach Practicing Domain-Driven Design , Millet, Leanpub Ubiquitäre Sprache Bounded Context Supporting Bounded Context Supporting Bounded Context Bounded Context Core Context Map Bounded Context Generic angewendet auf Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  36. 36. Domain Driven Design - Stabile Basis für langlebige Software 36 | 52 Wie werden die Ziele des strategischen Designs erreicht? Fachexperten und Entwicklung arbeiten zusammen  Kooperativ  Kommunikativ DDD ist ein andauernder Lernprozess über die Fachlichkeit  Iterativ  Explorativ  Kompetenzgewinn spiegelt sich in Ergebnissen wieder Sprache treibt und bestimmt das Vorgehen  Ubiquitäre Sprache beschreibt das gemeinsame Verständnis der Domäne  Bounded Context bestimmt einen sprachlichen Kontext Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  37. 37. Domain Driven Design - Stabile Basis für langlebige Software 37 | 52 Agenda Warum Domain Driven Design ? Strategisches Design - Konzepte im Problemraum Strategisches Design - Konzepte im Lösungsraum Taktisches Design und Architektur Essentials Abschluss Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  38. 38. Domain Driven Design - Stabile Basis für langlebige Software 38 | 52 Fachlichkeit im Zentrum der Softwareentwicklung Code Architektur Trennung von Fachlichkeit und Technologie Fachliche Durchgängigkeit durch tiefgehende Modellierung Problemraum Lösungsraum Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  39. 39. Domain Driven Design - Stabile Basis für langlebige Software 39 | 52 Agenda Warum Domain Driven Design ? Strategisches Design - Konzepte im Problemraum Strategisches Design - Konzepte im Lösungsraum Taktisches Design und Architektur Essentials Abschluss Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  40. 40. Domain Driven Design - Stabile Basis für langlebige Software 40 | 52 Erosion ihrer langlebigen Software Es dauert immer länger um Releases freizugeben Es ist fast nicht mehr möglich neue Technologien zu integrieren Fachliche Änderungen verstreuen sich über Ihre gesamte Anwendung  Oft ist gar nicht klar, welche Teile des Systems betroffen sind Kleine Änderungen haben große Auswirkungen  Zum Beispiel aufwendige Abnahme des Gesamtsystems Ihre Datenbankstruktur ist unübersichtlich  Es ist nicht klar, welche Tabellen miteinander zu tun haben Softwaresysteme unter Veränderungen | Was sind Microservices? | Aspekte der Microservice-Architektur | Zum Abschluss | Referenzen | Weiterführende Literatur Dann wird es Zeit, über Domain Driven Design nachzudenken
  41. 41. Domain Driven Design - Stabile Basis für langlebige Software 41 | 52 Domain First – Domäne steht im Zentrum Vorgehen stellt Fachlichkeit in den Mittelpunkt des Designs  Kollaboration zwischen Fachexperten und Entwicklung  Gemeinsames Verständnis der Fachlichkeit Domain Driven Design zielt auf eine fachliche Durchgängigkeit/Integrität  Bruch zwischen fachlicher Anforderung und technischer Umsetzung ist behoben  Fachliche Durchgängigkeit unterstützt die Beherrschung langlebiger Systeme Domain Driven Design zielt auf ein System autonomer Bausteine  Autonomie ist der Schlüssel zur Beherrschung langlebiger Systeme Domain Driven Design | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen
  42. 42. Domain Driven Design - Stabile Basis für langlebige Software 42 | 52 Domain First – Domäne steht im Zentrum Domänen-orientiertes Design  Explizites Design der reinen Fachlichkeit/Domänen Domänen-orientierte Dekomposition  Domain Distillation (Problemraum)  Bounded Context (Lösungsraum) Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  43. 43. Domain Driven Design - Stabile Basis für langlebige Software 43 | 52 Domain Driven Design DDD beschreibt Methoden und Prozesse  Domänen und Destillation  Ubiquitäre Sprache  Strategisches Design  Taktisches Design Verfahren und Techniken, um  Fachexperten und Entwicklung zusammenarbeiten zu lassen  Domäne in Subdomänen zu zerlegen  Die richtige Core-Domäne zu finden  Bounded Context voneinander abzugrenzen  Eine Bounded Context en Detail zu designen Siehe [Evans] Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  44. 44. Domain Driven Design - Stabile Basis für langlebige Software 44 | 52 Einsatz von DDD will überlegt sein Strategisches Design  Ubiquitäre Sprache, Domänen-Destillation und Bounded Context  . . . sind für das gesamte System zuträgliche Konzepte  Designansätze tragen in allen Domänen/Projekten Domain Driven Design in voller Ausprägung  Eignet sich für fachlich komplexe Systeme  D.h. inkl. taktischem Design, Architektur + DDD-Prozess  Konzentration auf Core Domain  Ist sehr aufwendig Domain Driven Design ist nicht die Lösung aller Probleme Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  45. 45. Domain Driven Design - Stabile Basis für langlebige Software 45 | 52 Auswirkungen von Domain Driven Design Entwickler bekommen ein neues Rollenverständnis Fachexperten bekommen ein neues Rollenverständnis Teams stehen im Zentrum der Entwicklung Zusammenarbeit in crossfunktionalen Teams Entwicklungsprozess muss sich anpassen Agiles Mindset unterstützt den Erfolg von Domain Driven Design Domain Driven Design | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen
  46. 46. Domain Driven Design - Stabile Basis für langlebige Software 46 | 52 Wie kann es losgehen? Fachexperten müssen den Wert von Domain Driven Design sehen  Müssen ggfs. überzeugt werden Entwickeln Sie ein ubiquitäre Sprache Lassen Sie Raum für Exploration  Die „richtige“ Lösung muss sich entwickeln können  Anforderungen so lange hinterfragen bis diese stabil sind Fangen Sie klein an  Piloten, um die Verfahren einzuüben Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  47. 47. Domain Driven Design - Stabile Basis für langlebige Software 47 | 52 Abschließende Bemerkungen Exakte Ausprägung von Domain Driven Design hängt vom Umfeld ab  Zusammenarbeit zwischen Fachexperten und Entwicklung  Einbettung in agiles Vorgehen Domain Driven Design benötigt Erfahrung  Wir können nur grundlegende Techniken und Vorgehensweisen vorstellen  Siehe Analysis Patterns: Reusable Object Models von Martin Fowler Domain Driven Design stabilisiert ihre Systeme Es lohnt sich Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  48. 48. Domain Driven Design - Stabile Basis für langlebige Software 48 | 52 Leseempfehlungen Domain-Driven Design: Tackling Complexity in the Heart of Software von E. Evans Implementing Domain-Driven Design von Vaughn Vernon Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  49. 49. Domain Driven Design - Stabile Basis für langlebige Software 49 | 52 Weiterführende Literatur https://weblogs.asp.net/ngur/Business-capabilities-or-business-processes- http://codebetter.com/gregyoung/2012/02/29/the-context-game-2/ https://hackernoon.com/how-to-define-service-boundaries-251c4fc0f205 https://hackernoon.com/wrong-ways-of-defining-service-boundaries- d9e313007bcc https://www.infoq.com/articles/ddd-contextmapping https://leanpub.com/Practicing-DDD; Scott Millett Patterns, Principles, and Practices of Domain-Driven Design; Scott Milet Rechtin E. and Maier M. The art of systems architecting, CRC Press, 2002, ISBN 0-8493-0440-7. Implementing Domain-Driven Design; Vaughn Vernon https://www.microsoftpressstore.com/articles/article.aspx?p=2248811 Analysis Patterns: Reusable Object Models von Martin Fowler Warum Domain Driven Design? | Problemraum | Lösungsraum | Taktisches Design und Architektur | Essentials | Abschluss | Referenzen | Ende
  50. 50. Domain Driven Design - Stabile Basis für langlebige Software 50 | 52 Impulsvorträge für Ihr Unternehmen Überblick über das gesamte Angebot an Impulsvorträgen unter: www.iks-gmbh.com/impulsvortraege Ihr Nutzen:  Unabhängiges, aktuelles Expertenwissen.  Individuell auf Ihr Publikum und Ihr Unternehmen zugeschnittene Vorträge.  Referenten mit langjähriger und branchenübergreifender Expertise in der IT- Beratung.  Praxisnahe Vorträge, die aus Projektarbeit entstanden sind, frei von Produktwerbung.  Ideale Ergänzung für Ihre Führungskräftetreffen, Abteilungsmeetings, Hausmessen, Innovation Days, Konferenzen, Open Spaces, Kick-off-Meetings oder Zukunftsworkshops.
  51. 51. WWW.IKS-GMBH.COM
  52. 52. Domain Driven Design - Stabile Basis für langlebige Software 52 | 52 Projekte. Beratung. Spezialisten.

×