- Theme: “High Level” – Aktion, die ein Akteur mit dem System durchführt.
- Domain Entity / Value Object: Typ des Gegenstands in der Domäne, der durch die Aktion erzeugt, gelesen, geändert oder gelöscht wird (CRUD – Operationen).
- Epic: “Low Level” – Aktion, die ein Akteur mit dem System durchführt und die dem Theme dienlich ist. Ein Epic als Ordnungsebene wird immer dann verwendet, wenn sich mehrere User Stories (siehe nächster Punkt) thematisch sinnvoll gruppieren lassen.
- User Story: “Low Level” – Altion, die ein Akteur mit dem System durchführt und die dem Theme dienlich ist.
- Acceptance Criteria: Atomare Anforderung an eine User Story, die nur noch den Zustand “erfüllt” oder “nicht erfüllt” annehmen kann.
Alles ist einfacher erklärt anhand eines Beispiels. Stellen wir uns vor, wir entwerfen ein Blogging-System a la WordPress. Typischerweise gibt es dort das Theme “Artikel verfassen”. Eine exemplarische (Teil-)Aufschlüsselung im Rahmen einer Domain Driven Story Map könnte etwa wie folgt aussehen:
Eine Domain Driven Story Map eignet sich besonders gut für domaingetriebene, datenzentrierte Anwendungen, also prinziell immer dann, wenn Domain Driven Design auch funktioniert und sinnvoll erscheint. Ich werde in Kürze noch mehr Details zu Domain Driven Design zusammentragen, die helfen werden, die Idee der Domain Driven Story Maps noch besser zu verstehen und als Tool effektiv anzuwenden.
PS: Mehr zu mir, also dem Autor dieses Artikels, finden Sie hier im Blog auf meinem Profil.
27. Januar 2011 um 22:47 Uhr
Wenn DDD zu etwas nicht zu gebrauchen ist, sind es CRUD-Operationen.
Im Gegenteil ist es sogar so, dass es dafür völlig ungeeignet ist.
DDD ist nur etwas für sehr komplexe Domains, zumal der Aufwand für die
konsequente Umsetzung recht hoch bis sehr sind.
30. Januar 2011 um 11:46 Uhr
Hallo Don Zampano -
vielen Dank für dein Feedback. Ich stimme dir zu, dass “CRUD” als Begriff im Rahmen dieses Artikels irreführend ist und schnell Assoziationen zu technischen Softwarepattern wie Active Record & Co. weckt. Um die Art der Realisierung einer etwaigen Persistenz ging es mir in dem Artikel aber eigentlich gar nicht. Viel mehr geht es mir darum, dass der Produkt Owner neben der Funktionalität auch ein Verständnis für die Objekte der Domäne bekommt, dies mit der Domain Driven Story Map ausdrückt und die gewonnene “Dimension” zur Strukturierung des Produkt Backlogs nutzt, also Stories und Epics um die jeweils primär betroffenen Objekte der Domäne gruppiert. Da sich in meinen Augen fast alle Funktionen in Softwaresystemen irgendwann oder irgendwie um das Lesen, Erzeugen, Verändern oder Löschen von Objekten der Domäne dreht, egal wie komplex oder simpel die Domäne ist, passt der Begriff CRUD eigentlich trotzdem ganz gut. Ob sich die Persistenz dann technisch über Active Record oder wie in DDD gefordert über Repositories realisieren lässt, ist sicherlich von der tatsächlichen Komplexität der Domäne abhängig – an der Konzeption ändern es in meinen Augen aber nichts. Für mich persönlich ist DDD auch mehr ein Tool für den Product Owner und insbesondere zur Kommunikation zwischen Product Owner und dem Scrum Realisierungsteam, als denn eine Vorgabe für Architektur oder die letztendliche technische Realisierung.
Gruß,
Michael