Kurze Ausführung zu dem aktuellen Trend der Microservices und dem von Adam Bien eingeführten Entity Control Boundary Pattern

1. Microservices
und das
Entity Control Boundary Pattern
Copyright and all intellectual property belongs to Brockhaus Group 1

2. Microservices in a nutshell
Microservices und Domain-driven Design
Service Design
Copyright and all intellectual property belongs to Brockhaus Group 2

3. Microservices in a nutshell
"Microservices" - yet another new term on the crowded streets of
software architecture. Although our natural inclination is to pass
such things by with a contemptuous glance, this bit of terminology
describes a style of software systems that we are finding more and
more appealing. We've seen many projects use this style in the last
few years, and results so far have been positive, so much so that for
many of our colleagues this is becoming the default style for building
enterprise applications. Sadly, however, there's not much information
that outlines what the microservice style is and how to do it.
--- Martin Fowler
Die wesentliche Entwurfsentscheidung basiert auf der vom​​Martin Fowler​vorgeschlagenen
Microservices-Ansatz​und dem Paradigma des​​Domain-driven Designs​. Neben der Unterteilung der
Applikation in die Layer entsprechend dem SOA Referenzmodell soll mittels des Ansatzes der
Microservices eine vertikale Unterteilung der Applikation in voneinander weitestgehend unabhängigen
Services ermöglicht werden.
Als Merkmale von Microservices werden abgeführt :
● Bei Microservices wird ​jedes Modul zu einem Service​– ein getrennter Prozess mit einer
Schnittstelle.
● Bei Microservices werden Funktionalitäten in ​fachliche Services​unterteilt, die ​einzeln
deployt​werden können.
● Microservices sollen so klein sein, dass sie von einem Menschen oder einem kleinen Team
verstanden und gewartet werden können (​10–100 Codezeilen​).
● Die Idee ist auch, dass ​Microservices einfach ersetzt werden können​, statt sie zu warten.
● Im ​Gegensatz zu einer SOA​nutzen Microservices leichtgewichtige Infrastrukturen und
Protokolle und können eine GUI enthalten.
Fachlich bilden unsere Services eine
geschlossene Funktionalität ab. Neue
Anforderungen werden in neuen
Services implementiert (Open/Closed
Principle). Einem grenzenlosen
Wachstum der Code Base bis hin zu
einem Monolithen ist damit ein für alle
mal ein Riegel vorgeschoben. Jeder
Service bleibt in Gänze verständlich
und wartbar.
Hierbei sind folgende Vorteile zu
sehen:
● Jeder Microservice ist
verhältnismäßig klein und für die Entwickler leicht zu verstehen.
● Jeder Microservice kann unabhängig von den anderen Services entwickelt, getestet und
deployed werden.
Copyright and all intellectual property belongs to Brockhaus Group 3

4. ● Jeder Microservice kann theoretisch in einer eigenen Technologie entwickelt werden (sofern
die verwendeten Kommunikationstechnologien dieses erlauben).
Uncle Bob​​(Bob Martin)​1​
beschreibt Microservices wie folgt:
● You can fire up your little MS and talk with it via REST. No other part of the system needs to
be running. Nobody can change a source file in a different part of the system, and screw your
little MS up. Your MS is immune to all the other code out there.
● You can test your MS with simple REST commands; and you can mock out other MSs in the
system with little dummy MSs that do just what your tests need them to do.
● Moreover, you can control the deployment. You don't have to coordinate with some huge
deployment effort, and merge deployment commands into nasty deployment scripts. You just
fire up your little MS and make sure it keeps running.
● You can use your own database. You can use your own webserver. You can use any language
you like. You can use any framework you like.
Microservices und Domain-driven Design
Das​​Domain-driven Design​stellt ebenfalls die Funktionalität in den Vordergrund. Das Design
komplexer Anwendungssyteme stellt hier die Fachlichkeit und die Fachlogik in den Vordergrund. In
diesem Zusammenhang ist insbesondere das Konzept der Domäne interessant:
● Domäne als abgegrenzes Fachgebiet, Geschäftsfeld oder Einsatzbereich
● Keine Abgrenzung nach Infrastruktur (Persistenz, UI, ...)
Domain-driven Design teilt große Modelle in
überschaubare Einheiten mittels sogenannter
Bounded Contexts​. Ein Bounded Context.
zeichnet sich dadurch aus, dass er die Hoheit
über eigene Ressourcen hat (oft eine
Datenbank). Gegebenenfalls besteht eine
Anwendung aber auch aus mehreren
Bounded Contexts, zwischen denen gezielt
Informationen transferiert werden. Durch die
Aufteilung behält jeder Context die Hoheit
über seine Ressourcen. Dadurch lässt sich
beispielsweise eine angemessene Technik
auswählen, ohne dass davon die anderen
Bounded Contexts der Anwendung betroffen
sind. Ein solcher Context betrachtet das gesamte Anwendungssystem in einem bestimmten Kontext,
daher der Name. Begriffe wie Kunde und Produkt können in verschiedenen Kontexten eine jeweils
leicht andere Bedeutung haben. Die Herausforderung liegt darin, eine Form der Modellierung zu
finden, die mit möglichst wenigen Abhängigkeiten auskommt.
Bei beiden Ansätzen steht die funktionale Dekomposition der Applikation in einzelne fachliche
Teilbereiche im Vordergrund.
Copyright and all intellectual property belongs to Brockhaus Group 4

5. Als illustrierendes Beispiel für eine solche Dekomposition soll hier das​​Aktivitätenmodell​der​​ISA 95
angeführt werden. Innerhalb dieses Modells kann jede der dargestellten Aktivitäten als eigener
Microservice / Bounded Context verstanden werden. Für das MDS Toolset müssten diese Elemente
identifiziert werden.
Die interne Architektur der Services steht
prinzipiell nicht im Vordergrund, sollte aber
Aspekte der Kommunikation und der Integration
berücksichtigen.
Hierzu sollte jeder Service mittels binärer
Aufrufe, Aufrufen über Web Services und RESTful
Services und asynchrone Aufrufe mittels
Messaging Systemen. Diese Aspekte werden im
Java EE Bereich insbesondere im Kontext des
Entity Control Boundary-Patterns​addressiert.
Service Design
"Ein Service repräsentiert ein potentiell wiederverwendbares Konzept
einer Anwendungsdomäne"
--- Wolfgang Pleus
Es gibt keine einheitliche Definition dessen, was ein Service ist. In dem Kontext der Microservices
steht die Fachlichkeit im Vordergrund, nicht die Technik, daher scheiden technische Merkmale als
Grundlage des Service Designs aus und der fachliche 'Inhalt' des Services rückt in den Vordergrund.
Technische Aspekte sind von fachlichen Aspekten entkoppelt und können im Bedarfsfall leicht
hinzugefügt werden (zu den Boundary Layer des Entity Control Boundary Patterns). Die Grundlage der
Implementierung des Service bildet der Service Kontrakt, vulgo die Schnittstelle und deren
Beschreibung. Für deren Design lassen sich keine allgemeingültigen Regeln oder Qualitätsmassstäbe
finden, doch gibt es einige Anregungen /​​Guidelines​zur Ausgestaltung.
Copyright and all intellectual property belongs to Brockhaus Group 5

6. Entity Control Boundary Pattern
Although Java EE 6 is far less complex than previous platform
versions, it can still be misused to create exaggerated and
bloated architectures.
--- Adam Bien
Obwohl bei​​Microservices​theoretisch jeder Service in einer eigenen
Technologie implementiert werden könnte, sollte für die einzelnen Services ein möglichst gleichartiges
Implementierungsschema gewählt werden; nur so können Entwickler innerhalb mehrerer Services
Aufgaben wahrnehmen.
Jede dieser Service-Komponenten erfüllt eine
spezifische Aufgabe, werden zur Erfüllung der
Aufgabe andere Services benötigt, dann ist es die
Aufgabe des Services, die entsprechenden
anderen Services zu nutzen. Das Pattern des
API-Gateway​s sollte unserer Meinung nach nur in
Ausnahmefällen verwendet werden. Unserer
Meinung nach eignet sich das​​Entity Control
Boundary Pattern​für die Implementierung
backendseitiger​​Microservices​besonders gut.
Hierbei wird hinsichtlich der Layer der einzelnen
Komponenten / Microservices zwischen den
Schnittstellen des​​Microservice​(Boundary), der
Geschäftslogik des​​Microservice​(Control) und der Persistenz des​​Microservice​(Entity) unterschieden.
Diese Unterscheidung korrespondiert mit den Layern des​​SOA Referenzmodells​.
Copyright and all intellectual property belongs to Brockhaus Group 6