Der Baustein Domain

---

Methode

Moti­vation für den Ein­satz

IT-Systeme gibt es in einem brei­ten Spek­trum. Monoli­thische Soft­ware bündelt die Bestand­teile des IT-Systems in untrenn­bare Gebilde und unter­schei­det nur zwischen Client und Server. Alter­nativ kann eine kom­plexe Soft­ware aus unab­hängi­gen Pro­zessen aufge­baut werden, die unter­ein­ander mit genorm­ten Pro­gram­mier­schnitt­stellen kommuni­zieren. Soft­ware hat immer eine Struk­tur, unab­hängig vom Archi­tektur­stil und der Program­mier­sprache.

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Melvin Edward Conway

Das Gesetz von Conway basiert auf der Beob­ach­tung, dass die Struk­tur der Soft­ware wesent­lich von der Pro­jekt­organi­sation beein­flusst wird. Der Bau­stein Domain ist sehr gut geeig­net, die Gren­zen und Über­gänge dieser Struk­turen sicht­bar zu machen.

Der Bau­stein Domain ist das Arte­fakt in der System­struk­tur, mit dem Autoren Bestand­teile der Soft­ware bün­deln, die eine starke Abhängig­keit von­ein­ander haben. Ziel ist immer, die Kom­plexi­tät der Soft­ware in den Griff zu bekom­men, einen Über­blick zu behal­ten und Zusam­men­hänge zu erken­nen.

---

Pro­zesse

Pro­jekt­manage­ment

Der Pro­dukt­­verant­wort­liche hat mit dem Bau­stein Domain die Mög­lich­keit, früh­zeitig und in Abstim­mung mit dem Team Gren­zen und Über­gängen in den Struk­tur der Soft­ware zu fixieren. Beson­ders in Pro­jekt­organi­sationen mit mehreren Teams, die an der Ent­wick­lung des Pro­duktes beteiligt sind, ist dieses Wissen vor­teil­haft. Selbst wenn das Produkt von einem ein­zigen Team ent­wickelt wird, kann die Anfor­derung eines unter­brechungs­freien Betriebs des IT-System dazu führen, dass ein weiteres Team einer Betriebs­organi­sation an der Soft­ware mit­wirkt. Der Bau­stein Domain trennt indivi­duell ent­wickel­te Dienste und Dienste einer bereit­gestell­ten Infra­struk­tur. Das ist förder­lich für die naht­lose Zusam­menar­beit der Teams.

 

---

Pro­zesse

Anfor­derungs­analyse

Der Pro­dukt­­verant­wort­liche hat mit den Bau­steinen Epic und Domain zwei Mög­lich­keiten, das Wissen über das Pro­dukt zu struk­turieren. Im Bau­stein Epic werden die Fähig­keiten der Soft­ware nach rein fach­lichen Gesichts­punk­ten gebün­delt. Der Bau­stein Domain grup­piert Bestand­teile der Soft­ware, die eine starke Abhängig­keit von­ein­ander haben. Folgt das Team beim Ent­wurf der Soft­ware den grund­legen­den Elemen­ten der Anwen­dungs­domäne sowie deren Beziehungen, dann ent­steht auto­matisch eine prüf­bare Bin­dung zwischen den Bau­steinen Epic und Domain.

 

---

Pro­zesse

Pro­dukt­entwick­lung

Der Bau­stein Domain macht starke Abhängig­keiten zwischen den Bestand­teilen der Soft­ware sicht­bar. Das sind wert­volle Hin­weise für die Leser bei der Ein­schätzung der Kriti­kali­tät von Änderungen an Schnitt­stellen. Schnitt­stellen inner­halb einer Anwen­dungs­domäne erfor­dern in der Regel weni­ger Abstim­mung als Schnitt­stellen zwischen ver­schie­denen Domänen oder an den System­grenzen. Auch der Umfang der Test­pläne steigt ent­sprechend.

---

Quali­tät

Seiten­vor­lage des Bau­steins

Confluence unter­stützt mit Seiten­vor­lagen die Idee der Bau­steine optimal. Das fol­gende Bei­spiel kann direkt als HTML im Editor der Seiten­vor­lagen ein­gefügt werden.

<h1>Überblick</h1>
<ac:structured-macro ac:macro-id="d2979c44-899c-417c-b700-bc10d55809e5" ac:name="section" ac:schema-version="1">
    <ac:rich-text-body>
    <ac:structured-macro ac:macro-id="2df65db9-2a6b-4001-a5f6-7e9fbb9ff023" ac:name="excerpt" ac:schema-version="1">
        <ac:parameter ac:name="atlassian-macro-output-type">BLOCK</ac:parameter>
        <ac:rich-text-body>
        <p>
            <ac:placeholder>Bitte hier eine kurze Erklärung der Domäne. </ac:placeholder>
        </p>
        </ac:rich-text-body>
    </ac:structured-macro>
    </ac:rich-text-body>
</ac:structured-macro>
<ac:structured-macro ac:macro-id="99bb74c6-5c1d-423a-8257-6c71d84e7737" ac:name="scroll-ignore" ac:schema-version="1">
    <ac:rich-text-body>
    <p>
        <ac:structured-macro ac:macro-id="ff1b1e51-1386-4880-a4c6-467e6111c29f" ac:name="contentbylabel" ac:schema-version="3">
        <ac:parameter ac:name="showSpace">false</ac:parameter>
        <ac:parameter ac:name="excerptType">simple</ac:parameter>
        <ac:parameter ac:name="cql">label in ("layout","service","event","entity") and parent = currentContent()</ac:parameter>
        </ac:structured-macro>
    </p>
    </ac:rich-text-body>
</ac:structured-macro>

---

Struk­tur

Eigen­schaf­ten des Bau­steins

Der Bau­stein Domain hat einen Steck­brief mit einer Kurz­beschrei­bung. Er repräsen­tiert eine Kontext­grenze (engl. bounded context) inner­halb der Soft­ware. Der Seiten­titel beginnt immer mit Domain. Durch die Seiten­vor­lage hat jede Seite das Stich­wort domain. Sie kann aber um weitere Schlag­worte ergänzt wer­den. Dadurch wird die Seite leich­ter auf­find­bar.

Der Bau­stein Domain bündelt eine wachsende Menge von Imple­men­tierungen, die mit den Bau­steinen Layout, Service, Event und Entity beschrie­ben wer­den.

Der Bau­stein Domain hat kei­nen Zustand.

Der Bau­stein Domain hat kei­nen Bezug zu einem Produkt­inkre­ment.

Der Bau­stein Domain wird in der Sprache der Ent­wick­ler geschrie­ben.