Domain Driven Design und die Archäologie des Modells

Irgendwann kommt der Zeitpunkt, an dem die Anwender der Software beginnen in den Begriffen des Modells zu denken und in diesem System zu handeln. Und spätestens wenn das Modell eine Eigendynamik gewinnt und anfängt sich weiterzuentwickeln, kann das sehr kuriose Folgen haben. Etwa dann, wenn nicht einmal der Anwender selbst seine eigene Business-Domäne versteht.

Welche Auswirkungen und Konsequenzen es haben kann, wenn sich das Modell selbstständig weiterentwickelt, haben wir in einem unserer Projekte herausgefunden. Wir zeigen, was genau passiert ist und verdeutlichen das zugrundeliegende Problem anhand eines fiktiven Beispiels. 

TL;DR 3 Thesen, die helfen können, das folgende Problem im eigenen Projekt zu bewältigen:

  • Für die Business-Analysten: Conway’s Law wirkt in beide Richtungen!
  • Für die Architekten: Archäologie gehört zum Job – und Relationen sind keine Dinge!
  • Für die Entwickler: Primare Keys in Intersection Tables sind die Wurzel (fast) allen Übels!

Inhalt:

  1. Warum eigentlich Domain Driven Design?
  2. Die Archäologie die dahinter steckt
  3. Wie wäre es mit einem Beispiel?
    3.1 Das Artefakt
    3.2 Pompeji
    3.3 Archäologie 101
    3.4 Genealogie
    3.5 Implementierungshinweise
  4. Fazit

Tagged .Speichere in deinen Favoriten diesen permalink.

Kommentare sind geschlossen.