Domain-Driven Design
Softwaremodelle aus dem Fachgebiet entwickeln, gemeinsam mit den Menschen, die seine Regeln kennen.
Was ist Domain-Driven Design?
Domain-Driven Design, kurz DDD, richtet die Modellierung von Software an einem Fachgebiet aus. Fachkundige und Entwicklungsteam klären gemeinsam Begriffe, Regeln und Zusammenhänge. Eine gemeinsame Sprache soll innerhalb eines festgelegten fachlichen Zusammenhangs dieselbe Bedeutung haben. Unterschiedliche Zusammenhänge können eigene Modelle benötigen; diese Grenze wird häufig Bounded Context genannt.
In einem erfundenen Betrieb meint der Vertrieb mit „Auftrag“ eine verkaufte Leistung, das Serviceteam einen eingeplanten Einsatz. Die Beteiligten beschreiben beide Bedeutungen und ihre Übergabe, statt stillschweigend ein einziges Datenmodell vorauszusetzen. Daraus können klarere Softwaregrenzen entstehen. DDD schreibt aber weder Microservices noch einen bestimmten Datenbanktyp vor. Wie Modelle technisch aufgeteilt und betrieben werden, ist eine zusätzliche Architekturentscheidung.
Quellen
Verwandte Begriffe
- SoftwarearchitekturGrundlegende Entscheidungen über Aufbau, Zusammenarbeit und Qualitätsziele eines Softwaresystems.
- Modularer MonolithEine gemeinsam ausgelieferte Anwendung mit ausdrücklich abgegrenzten inneren Modulen und ihren Schnittstellen.
- Cache StampedeEin Cache Stampede entsteht, wenn gleichzeitige Anfragen dieselben Daten im Cache nicht finden und dieselbe teure Arbeit mehrfach starten.
- BackpressureBackpressure passt den Datenzufluss an die Verarbeitungskapazität des Empfängers an, indem dieser eine Verlangsamung oder Pause signalisiert.
- Race ConditionEin fehlerhaftes Ergebnis hängt von der zeitlichen Reihenfolge überlappender Zugriffe ab.
- Memory LeakNicht mehr benötigter Speicher bleibt während des Betriebs unnötig gebunden.
Beiträge zum Thema
Ihr Vorhaben mit ASES
Beschreiben Sie uns Ihr Vorhaben. Wir melden uns mit einer ersten Einschätzung.