Struktur

Meta­modell der Bau­steine

Das Meta­modell der Bau­steine einer Pro­dukt­doku­mentation rich­tet sich an jene Per­sonen, die ein abstrak­tes Modell für das Ver­ständ­nis der Zusam­men­hänge brau­chen. Das Meta­modell soll eine Orien­tierung für den Ein­satz von cards+ und der effek­tiven Ver­wendung der Bau­steine im Wiki sein.

Die Bau­steine der System­struk­tur orien­tie­ren sich auch an Kon­zep­ten, die Eric Evans in sei­nem Buch »Domain-Driven Design: Tack­ling Com­plexity in the Heart of Soft­ware« sehr aus­führ­lich beschreibt. Das gilt im Beson­de­ren für die gemein­same Sprache (engl. ubiqui­tous language) und der Fest­legung von Kon­text­gren­zen (engl. bounded con­text). Die gemein­same Sprache fin­det bei cards+ Aus­druck durch das Glossar und die konse­quente Ver­wen­dung der Sei­ten­titel der Bau­steine im Wiki ent­spre­chend dem Prin­zip COD. Kon­text­grenzen werden in den Bau­steinen Domain (Grup­pie­rung eng ver­wandter Dienste und Objekte) und Service (z.B. für die Grup­pie­rung der Micro­services eines Dienstes) defi­niert.

Ver­ein­fach­tes UML-Klassen­dia­gramm

Die Bau­steine der System­beschrei­bung sind streng hierar­chisch struk­turiert und unters­tützen so die Arbeits­weise top down bei der Ana­lyse. Das bedeu­tet, dass ein Autor die Gren­zen der Soft­ware im Bau­stein Topic beschreibt. In seiner weiteren Ana­lyse der Fähig­keiten der Soft­ware gibt er im Bau­stein Epic einen Über­blick. Den Bau­stein Case nutzt er, um jede einzelne Fähig­keit der Soft­ware zu erfassen und mit den Essenz­schritten in der Lösung den Über­gang zu den Bau­steinen der System­struk­tur zu schaffen.

Die Bau­steine der System­struk­tur haben das Ziel, die Struk­tur der Soft­ware abzu­bilden. Abhän­gig vom Archi­tektur­stil erge­ben sich durch den Bau­stein Domain Grup­pen von Diensten (Bau­stein Service) und Objekten (Bau­steine Event bzw. Entity). Der Bau­stein Task ist Platz­halter für Hand­lungs­anweisung, die eine Betriebs­organi­sation braucht, um einen unter­bre­chungs­losen und stö­rungs­freien Betrieb des IT-Systems zu gewähr­leis­ten. Er ist nicht mit einer Vor­lage “genormt”, weil Auf­bau und Inhalt ganz stark von den Bedürf­nissen der Betriebs­organi­sation bestimmt werden.

Die Bau­steine für den Archi­tektur­entwurf haben keine Struk­tur. Ihr Ziel ist es, alle Ent­schei­dungen im Bau­stein Decision und über­greifende oder wieder­holt einge­setzte Kon­zepte im Bau­stein Spec fest­zu­hal­ten. Sie haben die Auf­gabe, den Archi­tektur­stil nach­voll­zieh­bar zu beschrei­ben. Das ist ein wich­tiges Ele­ment der Kommuni­kation im Team.


Struk­tur

Dienste mit REST-API

In diesem Archi­tektur­stil besteht das IT-System aus einer Menge von Diens­ten, die eine Abfrage­schnitt­stelle (engl. query interface) mit einem REST-API anbie­ten. In diesem Archi­tektur­stil besteht eine starke Lauf­zeit­kopp­lung zwischen den Diensten und eine starke Abhängig­keit durch gemeins­am genutzte Infor­mations­objekte.

Es gilt die Prä­misse, dass ein Dienst eine kon­krete Funktio­nali­tät reali­siert, die durch den Bau­stein Epic fach­lich begrenzt wird. Die Imple­men­tierung der REST-API wird durch den Bau­stein Spec kon­kreti­siert. Die Frei­heits­grade bei der Techno­logie­wahl inner­halb eines Dienstes werden durch Ent­schei­dungen im Bau­sein Decision beschränkt.

Jeder Dienst wird mit dem Bau­stein Service im Wiki doku­men­tiert. Als Spezifi­kation bie­tet sich die Ver­öffent­lichung mit OpenAPI oder RAML an.

Jedes an der Schnittstelle relevante Infor­mations­objekt wird mit dem Bau­stein Entity im Wiki doku­mentiert. Die Spezifi­kation der Infor­mations­objekte für das REST-API ist in der Regel bereits in der Spezifi­kation des REST-API ent­halten. Der Bau­stein Entity beschränkt sich in seinem Inhalt daher auf die Ver­mitt­lung von Wissen, das für ein tieferes, über die reine Struk­tur hinaus­gehen­des Ver­ständ­nis not­wen­dig ist.

Ein Kompo­nenten­über­blick im Wiki nutzt die Bau­steine Service und Entity für eine visu­elle Dar­stel­lung und macht ihre Zusam­men­hänge und Daten­flüsse sicht­bar.


Struk­tur

Dienst mit asyn­chro­nen Nach­richten

In diesem Archi­tektur­stil besteht das IT-System aus einer Menge von Diens­ten, die Daten event-basiert ver­arbei­ten (engl. streaming) und über Nach­richten­kanäle asyn­chron ver­teilen (engl. broadcast). In diesem Archi­tektur­stil besteht eine schwache Lauf­zeit­kopp­lung zwischen den Diensten. Die Abhängig­keit durch gemein­sam genutzte Nach­richten­objekte kann mit dem Einsatz einer Schema­evolution redu­ziert werden.

Es gilt die Prä­misse, dass ein Dienst eine kon­krete Funktio­nali­tät reali­siert, die durch den Bau­stein Epic fach­lich begrenzt wird. Die Imple­men­tierung der Nach­richten­kanäle wird durch den Bau­stein Spec kon­kreti­siert. Die Frei­heits­grade bei der Techno­logie­wahl inner­halb des Dienstes werden durch Ent­schei­dungen im Bau­sein Decision beschränkt.

Jeder Dienst wird mit dem Bau­stein Service im Wiki doku­men­tiert. Für die Spezifi­kation bie­tet sich der Ein­satz von Asciidoc an.

Jedes an der Schnitt­stel­le rele­vante Nach­richten­objekt wird mit dem Bau­stein Event im Wiki doku­mentiert. Für die Spezifi­kation eines Nach­richten­objek­tes bietet sich die Ver­wen­dung von Avro an. Der Bau­stein Event beschränkt sich in seinem Inhalt nur mehr auf die Ver­mitt­lung von Wissen, das für ein tieferes, über die reine Struk­tur hinaus­gehen­des Ver­ständ­nis not­wen­dig ist.

Ein Kompo­nenten­über­blick im Wiki nutzt die Bau­steine Service und Event für eine visu­elle Dar­stel­lung und macht ihre Zusam­men­hänge und Daten­flüsse sicht­bar.


Struk­tur

Dienste im Appli­kations­ser­ver