Microservices
und das
Entity Control Boundary Pattern
Copyright and all intellectual property belongs to Brockhaus Group 1
Microservices in a nutshell
Microservices und Domain-driven Design
Service Design
Copyright and all intellectual property ...
Microservices in a nutshell
"Microservices" - yet another new term on the crowded streets of
software architecture. Althou...
● Jeder Microservice kann theoretisch in einer eigenen Technologie entwickelt werden (sofern
die verwendeten Kommunikation...
Als illustrierendes Beispiel für eine solche Dekomposition soll hier das​​Aktivitätenmodell​der​​ISA 95
angeführt werden. ...
Entity Control Boundary Pattern
Although Java EE 6 is far less complex than previous platform
versions, it can still be mi...
Nächste SlideShare
Wird geladen in …5
×

Microservices und das Entity Control Boundary Pattern

938 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
938
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
73
Aktionen
Geteilt
0
Downloads
6
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Microservices und das Entity Control Boundary Pattern

  1. 1. Microservices und das Entity Control Boundary Pattern Copyright and all intellectual property belongs to Brockhaus Group 1
  2. 2. Microservices in a nutshell Microservices und Domain-driven Design Service Design Copyright and all intellectual property belongs to Brockhaus Group 2
  3. 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. 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. 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. 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

×