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 abstra­ktes 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 (Grup­pie­rung der Micro­services eines Dienstes) defi­niert.

Agile Soft­ware-Ent­wick­lung har­mon­niert sehr gut mit Idee der Micro­services. Es ist in der Regel mög­lich, in einer Ite­ration einen Wert für das Pro­dukt­inkre­ment zu schaf­fen. Sie haben klare Schnitt­stel­len, was das paral­lele Arbei­ten im Team erleich­tert.

In short, the micro­service architec­tural style is an approach to develo­ping a single appli­cation as a suite of small services, each running in its own process and communi­cating with light­weight mechanisms, often an HTTP resource API. These services are built around business capa­bili­ties and indepen­dently deploy­able by fully auto­mated deploy­ment machi­nery. There is a bare minimum of centra­lized manage­ment of these services, which may be written in different pro­gramming languages and use different data storage techno­logies.

Martin Fowler

Spricht man von einem Micro­service, dann meint man damit einen bestimm­ten Archi­tektur­stil. Das bedeu­tet, es gibt mehr als einen Weg, ein Micro­service zu program­mieren. Der Archi­tektur­stil bestimmt auch, wie Micro­services mit­einander ver­bunden sind, um Daten auszu­tau­schen. Um dem Team in der agi­len Soft­ware-Ent­wick­lung den maxi­malen Spiel­raum für Experi­mente und kon­tinu­ier­liche Ver­besserun­gen der Code-Basis (engl. refactoring) zu geben, ver­wendet cards+ den Begriff Dienst als Abstrak­tion. Ein Dienst kann daher in der ein­fach­sten Form ein ein­zelnes Micro­service sein. Es macht aber aus Sicht einer robus­ten Pro­dukt­doku­men­tation sehr häufig Sinn, eine Gruppe von Micro­services zusam­men­zu­fas­sen, die eine hohe Kohä­sion haben.

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, ein Autor die Grenzen der Software (Topic) definiert und seine Ana­lyse der Fähig­keiten der Soft­ware vom Gro­ben (Epic) ins Fei­ne (Case) ent­wickeln kann. Der Bau­stein Case bil­det außer­dem durch die Essenz­schritte in der Lösung den Über­gang zu den Bau­steinen der System­struk­tur.

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 da­durch Grup­pen (Domain) von Diensten (Service) und Objekten (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. Hand­lungs­anwei­sungen für den Betrieb des IT-Systems. 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 (Decision) und Kon­zepte (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