Unab­hängig vom Archi­tektur­stil besteht jedes IT-System aus Diensten. Ein Micro­service mit einem REST-API ist ein ein Dienst. In einem reaktiven IT-System gibt es Dienste, die Nach­richten­objekte produ­zieren oder konsu­mieren. Auch in mono­lithischen IT-Systemen mit klassi­schen Appli­kations­servern lassen sich Dienste identi­fizieren. Der Bau­stein Service ist ein Arte­fakt der System­struk­tur, mit dem wir solche Artefakte der Soft­ware-Ent­wick­lung doku­mentieren. Dabei steht der fach­liche Nutzen des Dienstes im Vorder­grund. Der Titel des Bau­steins gibt einem Dienst einen ein­deutigen Namen.

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

Agile Soft­ware-Ent­wick­lung har­mo­niert sehr gut mit dem Kon­zept der Micro­services. 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.

Autoren wollen im Bau­stein Service nur das doku­mentieren, was Ent­wick­ler nicht durch les­bare Teile vom Code oder code-nahe Arte­fakte bereits aus­reichend gut doku­mentiert haben. Mit Swagger bzw. OpenAPI kann beispiels­weise ein auf REST basieren­der Dienst spezifi­ziert werden, mit WSDL ein auf SOAP basieren­der Dienst. Autoren beschrei­ben im Wiki nur, was sich gar nicht oder sehr schwer aus dem Code heraus­lesen lässt. Sie erläutern Code ausschließlich dort, wo es notwendig ist.

Der Pro­dukt­­verant­wort­liche hat mit dem Bau­stein Service die Mög­lich­keit, früh­zeitig einen wich­tigen Dienst als Ent­wurf zu erfassen, wenn es für das Ver­ständnis der Anwen­dungs­domäne hilf­reich ist. Er macht das in Abstim­mung mit dem Team.

Im Steck­brief des Bau­steins befindet sich eine Liste der geplan­ten Techno­logien für die Implemen­tierung des Dienstes. Das ist eine sehr wert­volle Infor­mation für das Archi­tektur­manage­ment, um Themen wie Lizenz­kosten, tech­nische Unter­stützung vom Her­steller oder unter­nehmens­weite Vor­gaben recht­zeitig zu behan­deln.

Der Pro­dukt­­verant­wort­liche hat mit dem Bau­stein Service die Mög­lich­keit, alle ein- und ausgehenden Daten und das Verhalten eines Dienstes zu beschrei­ben, die wich­tig für das Ver­ständnis der Fähig­keiten der Soft­ware sind.

Beson­ders bei Diensten, die Schnitt­stellen des IT-Systems zu anderen IT-Systemen reali­sieren, besteht oft die Not­wendig­keit, früh­zeitig Daten­struk­turen, Proto­kolle und nicht funktio­nale Aspekte wie Sicher­heit oder Robust­heit zu fixie­ren. Er macht das in Abstim­mung mit dem Team.

Der Bau­stein Service ist für Leser (z.B. Ent­wick­ler oder Tester) der zen­trale Ein­stieg, um sich über die Bedeu­tung eines Dienstes zu infor­mieren. Der Über­blick im Bau­stein muss jeden Leser in die Lage ver­setzen, den Dienst fach­lich einzu­ordnen. Über die Ver­knüpfung der ein- und aus­gehenden Daten mit den Bau­steinen Entity oder Event bekommt ein Leser Infor­mationen zu Objekten, die eine wich­tige Rolle in der Daten­ver­arbei­tung und -spei­cherung spielen. In der im Bau­stein ver­öffent­lichten Spezifi­kation finden Leser alle Details zur Imple­mentierung des Dienstes.

Gemäß Prinzip COD gilt der Titel des Bau­steins und die Namen der beschrie­benen Eigen­schaften als Vor­gabe für den Namen der Imple­mentierungs­klasse eines Dienstes. Mit dieser ein­­fach umzu­­setzen­den Regel muss kein Autor mehr eine spezi­elle Doku­­mentation im Wiki schrei­ben, um einen Dienst mit der tech­­nischen Lösung zu ver­­knüpfen. Der Titel des Bau­steins reicht als Ein­­stieg in die Imple­­mentierung.