SlideShare ist ein Scribd-Unternehmen logo
1 von 6
Downloaden Sie, um offline zu lesen
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 belongs to Brockhaus Group 2
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
● 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
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
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

Weitere ähnliche Inhalte

Was ist angesagt?

Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?
Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?
Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?DC CONSULTANTS
 
Modernizing applications with Amazon EKS - MAD304 - Santa Clara AWS Summit.pdf
Modernizing applications with Amazon EKS - MAD304 - Santa Clara AWS Summit.pdfModernizing applications with Amazon EKS - MAD304 - Santa Clara AWS Summit.pdf
Modernizing applications with Amazon EKS - MAD304 - Santa Clara AWS Summit.pdfAmazon Web Services
 
91APP: 從 "零" 開始的 DevOps
91APP: 從 "零" 開始的 DevOps91APP: 從 "零" 開始的 DevOps
91APP: 從 "零" 開始的 DevOpsAndrew Wu
 
Introdução a DevOps e Continuous delivery agileday
Introdução a DevOps e Continuous delivery   agiledayIntrodução a DevOps e Continuous delivery   agileday
Introdução a DevOps e Continuous delivery agiledayCarlos Felippe Cardoso
 
Domain-driven design - eine Einführung
Domain-driven design - eine EinführungDomain-driven design - eine Einführung
Domain-driven design - eine Einführungdie.agilen GmbH
 
No Onions, No Tiers - An Introduction to Vertical Slice Architecture by Bill ...
No Onions, No Tiers - An Introduction to Vertical Slice Architecture by Bill ...No Onions, No Tiers - An Introduction to Vertical Slice Architecture by Bill ...
No Onions, No Tiers - An Introduction to Vertical Slice Architecture by Bill ...Alex Cachia
 
PHP AST 徹底解説
PHP AST 徹底解説PHP AST 徹底解説
PHP AST 徹底解説do_aki
 
Docker Explained | What Is A Docker Container? | Docker Simplified | Docker T...
Docker Explained | What Is A Docker Container? | Docker Simplified | Docker T...Docker Explained | What Is A Docker Container? | Docker Simplified | Docker T...
Docker Explained | What Is A Docker Container? | Docker Simplified | Docker T...Edureka!
 
Introduction à la démarche Devops
Introduction à la démarche DevopsIntroduction à la démarche Devops
Introduction à la démarche DevopsRomain Chalumeau
 
Gitops: a new paradigm for software defined operations
Gitops: a new paradigm for software defined operationsGitops: a new paradigm for software defined operations
Gitops: a new paradigm for software defined operationsMariano Cunietti
 
DevOps的神鬼奇航
DevOps的神鬼奇航DevOps的神鬼奇航
DevOps的神鬼奇航Edward Kuo
 
DevOps Culture
DevOps CultureDevOps Culture
DevOps Culturerouanw
 
Domain Driven Design
Domain Driven DesignDomain Driven Design
Domain Driven DesignRyan Riley
 
컨테이너 기술과 가상화 기술의 주요한 차이점
컨테이너 기술과 가상화 기술의 주요한 차이점컨테이너 기술과 가상화 기술의 주요한 차이점
컨테이너 기술과 가상화 기술의 주요한 차이점Opennaru, inc.
 
About DevOps in simple steps
About DevOps in simple stepsAbout DevOps in simple steps
About DevOps in simple stepsIhor Odynets
 

Was ist angesagt? (20)

Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?
Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?
Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?
 
Modernizing applications with Amazon EKS - MAD304 - Santa Clara AWS Summit.pdf
Modernizing applications with Amazon EKS - MAD304 - Santa Clara AWS Summit.pdfModernizing applications with Amazon EKS - MAD304 - Santa Clara AWS Summit.pdf
Modernizing applications with Amazon EKS - MAD304 - Santa Clara AWS Summit.pdf
 
91APP: 從 "零" 開始的 DevOps
91APP: 從 "零" 開始的 DevOps91APP: 從 "零" 開始的 DevOps
91APP: 從 "零" 開始的 DevOps
 
Introdução a DevOps e Continuous delivery agileday
Introdução a DevOps e Continuous delivery   agiledayIntrodução a DevOps e Continuous delivery   agileday
Introdução a DevOps e Continuous delivery agileday
 
Domain-driven design - eine Einführung
Domain-driven design - eine EinführungDomain-driven design - eine Einführung
Domain-driven design - eine Einführung
 
No Onions, No Tiers - An Introduction to Vertical Slice Architecture by Bill ...
No Onions, No Tiers - An Introduction to Vertical Slice Architecture by Bill ...No Onions, No Tiers - An Introduction to Vertical Slice Architecture by Bill ...
No Onions, No Tiers - An Introduction to Vertical Slice Architecture by Bill ...
 
PHP AST 徹底解説
PHP AST 徹底解説PHP AST 徹底解説
PHP AST 徹底解説
 
Azure devops
Azure devopsAzure devops
Azure devops
 
XAML Islands
XAML IslandsXAML Islands
XAML Islands
 
Docker Explained | What Is A Docker Container? | Docker Simplified | Docker T...
Docker Explained | What Is A Docker Container? | Docker Simplified | Docker T...Docker Explained | What Is A Docker Container? | Docker Simplified | Docker T...
Docker Explained | What Is A Docker Container? | Docker Simplified | Docker T...
 
An introduction to DevOps
An introduction to DevOpsAn introduction to DevOps
An introduction to DevOps
 
Introduction à la démarche Devops
Introduction à la démarche DevopsIntroduction à la démarche Devops
Introduction à la démarche Devops
 
Gitops: a new paradigm for software defined operations
Gitops: a new paradigm for software defined operationsGitops: a new paradigm for software defined operations
Gitops: a new paradigm for software defined operations
 
DevOps的神鬼奇航
DevOps的神鬼奇航DevOps的神鬼奇航
DevOps的神鬼奇航
 
DevOps Culture
DevOps CultureDevOps Culture
DevOps Culture
 
Domain Driven Design
Domain Driven DesignDomain Driven Design
Domain Driven Design
 
컨테이너 기술과 가상화 기술의 주요한 차이점
컨테이너 기술과 가상화 기술의 주요한 차이점컨테이너 기술과 가상화 기술의 주요한 차이점
컨테이너 기술과 가상화 기술의 주요한 차이점
 
Oficina docker
Oficina dockerOficina docker
Oficina docker
 
About DevOps in simple steps
About DevOps in simple stepsAbout DevOps in simple steps
About DevOps in simple steps
 
Introduction to DDD
Introduction to DDDIntroduction to DDD
Introduction to DDD
 

Andere mochten auch

Research Presentation for Cyberscholars
Research Presentation for CyberscholarsResearch Presentation for Cyberscholars
Research Presentation for CyberscholarsDanielle Martin
 
Daniel Southern Management Group
Daniel Southern Management GroupDaniel Southern Management Group
Daniel Southern Management Groupdanielsouthern
 
Responsive Design - Quick & Dirty
Responsive Design - Quick & DirtyResponsive Design - Quick & Dirty
Responsive Design - Quick & DirtyArno Selhorst
 
Unit Tests are Overrated (NDCOslo 2013)
Unit Tests are Overrated (NDCOslo 2013)Unit Tests are Overrated (NDCOslo 2013)
Unit Tests are Overrated (NDCOslo 2013)Lars-Erik Kindblad
 
Webinar: Responsive Design
Webinar: Responsive DesignWebinar: Responsive Design
Webinar: Responsive Designkuehlhaus AG
 
Application Architecture by Lars-Erik Kindblad, Capgemini
Application Architecture by Lars-Erik Kindblad, CapgeminiApplication Architecture by Lars-Erik Kindblad, Capgemini
Application Architecture by Lars-Erik Kindblad, CapgeminiLars-Erik Kindblad
 
Avoid code duplication! Principles & Patterns
Avoid code duplication! Principles & PatternsAvoid code duplication! Principles & Patterns
Avoid code duplication! Principles & PatternsLars-Erik Kindblad
 
Introduction to FluentData - The Micro ORM
Introduction to FluentData - The Micro ORMIntroduction to FluentData - The Micro ORM
Introduction to FluentData - The Micro ORMLars-Erik Kindblad
 
Dependency Injection vs Service Locator - Best Practice
Dependency Injection vs Service Locator - Best PracticeDependency Injection vs Service Locator - Best Practice
Dependency Injection vs Service Locator - Best PracticeLars-Erik Kindblad
 
How to build more reliable, robust and scalable distributed systems
How to build more reliable, robust and scalable distributed systemsHow to build more reliable, robust and scalable distributed systems
How to build more reliable, robust and scalable distributed systemsLars-Erik Kindblad
 
Application Architecture April 2014
Application Architecture April 2014Application Architecture April 2014
Application Architecture April 2014Lars-Erik Kindblad
 
Anforderungsanalyse und UML Grundlagen
Anforderungsanalyse und UML GrundlagenAnforderungsanalyse und UML Grundlagen
Anforderungsanalyse und UML GrundlagenChristian Baranowski
 
Domain Driven Design und Nosql
Domain Driven Design und Nosql Domain Driven Design und Nosql
Domain Driven Design und Nosql ArangoDB Database
 
Mobile Patterns - Wie Apps und Co. digitale Interfaces revolutionieren
Mobile Patterns - Wie Apps und Co. digitale Interfaces revolutionierenMobile Patterns - Wie Apps und Co. digitale Interfaces revolutionieren
Mobile Patterns - Wie Apps und Co. digitale Interfaces revolutionierenMarkus Greve
 
The Single Responsibility Principle
The Single Responsibility PrincipleThe Single Responsibility Principle
The Single Responsibility PrincipleLars-Erik Kindblad
 
Publish & Subscribe to events using an Event Aggregator
Publish & Subscribe to events using an Event AggregatorPublish & Subscribe to events using an Event Aggregator
Publish & Subscribe to events using an Event AggregatorLars-Erik Kindblad
 

Andere mochten auch (20)

Research Presentation for Cyberscholars
Research Presentation for CyberscholarsResearch Presentation for Cyberscholars
Research Presentation for Cyberscholars
 
2012n01
2012n012012n01
2012n01
 
Daniel Southern Management Group
Daniel Southern Management GroupDaniel Southern Management Group
Daniel Southern Management Group
 
Responsive Design - Quick & Dirty
Responsive Design - Quick & DirtyResponsive Design - Quick & Dirty
Responsive Design - Quick & Dirty
 
Ready or not: No UI vom Verschwinden des Graphical User Interfaces
Ready or not: No UI vom Verschwinden des Graphical User InterfacesReady or not: No UI vom Verschwinden des Graphical User Interfaces
Ready or not: No UI vom Verschwinden des Graphical User Interfaces
 
Unit Tests are Overrated (NDCOslo 2013)
Unit Tests are Overrated (NDCOslo 2013)Unit Tests are Overrated (NDCOslo 2013)
Unit Tests are Overrated (NDCOslo 2013)
 
Webinar: Responsive Design
Webinar: Responsive DesignWebinar: Responsive Design
Webinar: Responsive Design
 
Application Architecture by Lars-Erik Kindblad, Capgemini
Application Architecture by Lars-Erik Kindblad, CapgeminiApplication Architecture by Lars-Erik Kindblad, Capgemini
Application Architecture by Lars-Erik Kindblad, Capgemini
 
Avoid code duplication! Principles & Patterns
Avoid code duplication! Principles & PatternsAvoid code duplication! Principles & Patterns
Avoid code duplication! Principles & Patterns
 
Introduction to FluentData - The Micro ORM
Introduction to FluentData - The Micro ORMIntroduction to FluentData - The Micro ORM
Introduction to FluentData - The Micro ORM
 
Dependency Injection vs Service Locator - Best Practice
Dependency Injection vs Service Locator - Best PracticeDependency Injection vs Service Locator - Best Practice
Dependency Injection vs Service Locator - Best Practice
 
How to build more reliable, robust and scalable distributed systems
How to build more reliable, robust and scalable distributed systemsHow to build more reliable, robust and scalable distributed systems
How to build more reliable, robust and scalable distributed systems
 
The Fluent Interface Pattern
The Fluent Interface PatternThe Fluent Interface Pattern
The Fluent Interface Pattern
 
Systementwurf mit UML
Systementwurf mit UMLSystementwurf mit UML
Systementwurf mit UML
 
Application Architecture April 2014
Application Architecture April 2014Application Architecture April 2014
Application Architecture April 2014
 
Anforderungsanalyse und UML Grundlagen
Anforderungsanalyse und UML GrundlagenAnforderungsanalyse und UML Grundlagen
Anforderungsanalyse und UML Grundlagen
 
Domain Driven Design und Nosql
Domain Driven Design und Nosql Domain Driven Design und Nosql
Domain Driven Design und Nosql
 
Mobile Patterns - Wie Apps und Co. digitale Interfaces revolutionieren
Mobile Patterns - Wie Apps und Co. digitale Interfaces revolutionierenMobile Patterns - Wie Apps und Co. digitale Interfaces revolutionieren
Mobile Patterns - Wie Apps und Co. digitale Interfaces revolutionieren
 
The Single Responsibility Principle
The Single Responsibility PrincipleThe Single Responsibility Principle
The Single Responsibility Principle
 
Publish & Subscribe to events using an Event Aggregator
Publish & Subscribe to events using an Event AggregatorPublish & Subscribe to events using an Event Aggregator
Publish & Subscribe to events using an Event Aggregator
 

Ähnlich wie Microservices und das Entity Control Boundary Pattern

BATbern41 Die Evolution zu Microservices
BATbern41 Die Evolution zu MicroservicesBATbern41 Die Evolution zu Microservices
BATbern41 Die Evolution zu MicroservicesBATbern
 
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSPSoftware Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSPChristian Guenther
 
ZüRich Ii Mobile App Final V3
ZüRich Ii Mobile App Final V3ZüRich Ii Mobile App Final V3
ZüRich Ii Mobile App Final V3guest08d4be
 
Artikel Schweizer Bank: SOA als Grundlage für «Composite Applications"​
Artikel Schweizer Bank: SOA als Grundlage für «Composite Applications"​Artikel Schweizer Bank: SOA als Grundlage für «Composite Applications"​
Artikel Schweizer Bank: SOA als Grundlage für «Composite Applications"​Peter Affolter
 
PLM Open Hours - Cloud PLM und PLM Trends
PLM Open Hours - Cloud PLM und PLM TrendsPLM Open Hours - Cloud PLM und PLM Trends
PLM Open Hours - Cloud PLM und PLM TrendsIntelliact AG
 
CLOUDSERVICES FÜR ISVs
CLOUDSERVICES FÜR ISVsCLOUDSERVICES FÜR ISVs
CLOUDSERVICES FÜR ISVsacentrix GmbH
 
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​Peter Affolter
 
Innovations- und Informationskultur mit Web 2.0 (2010)
Innovations- und Informationskultur mit Web 2.0 (2010)Innovations- und Informationskultur mit Web 2.0 (2010)
Innovations- und Informationskultur mit Web 2.0 (2010)Intelliact AG
 
Microservices – die Architektur für Agile-Entwicklung?
Microservices – die Architektur für Agile-Entwicklung?Microservices – die Architektur für Agile-Entwicklung?
Microservices – die Architektur für Agile-Entwicklung?Christian Baranowski
 
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdfDACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdfDNUG e.V.
 
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...Peter Affolter
 
00 Einleitung und Übersicht zur COMLINE Cloud Service Plattform - CSP
00 Einleitung und Übersicht zur COMLINE Cloud Service Plattform - CSP00 Einleitung und Übersicht zur COMLINE Cloud Service Plattform - CSP
00 Einleitung und Übersicht zur COMLINE Cloud Service Plattform - CSPChristian Guenther
 
Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...
Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...
Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...Peter Affolter
 
Der erste Schritt – idealtypische Wege in die Cloud und in der Cloud für Unte...
Der erste Schritt – idealtypische Wege in die Cloud und in der Cloud für Unte...Der erste Schritt – idealtypische Wege in die Cloud und in der Cloud für Unte...
Der erste Schritt – idealtypische Wege in die Cloud und in der Cloud für Unte...AWS Germany
 
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.QAware GmbH
 
Modulare Enterprise Systeme - Eine Einführung
Modulare Enterprise Systeme - Eine EinführungModulare Enterprise Systeme - Eine Einführung
Modulare Enterprise Systeme - Eine EinführungAndreas Weidinger
 
Steinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionSteinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionQAware GmbH
 
Steinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionSteinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionQAware GmbH
 

Ähnlich wie Microservices und das Entity Control Boundary Pattern (20)

BATbern41 Die Evolution zu Microservices
BATbern41 Die Evolution zu MicroservicesBATbern41 Die Evolution zu Microservices
BATbern41 Die Evolution zu Microservices
 
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSPSoftware Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
 
ZüRich Ii Mobile App Final V3
ZüRich Ii Mobile App Final V3ZüRich Ii Mobile App Final V3
ZüRich Ii Mobile App Final V3
 
Artikel Schweizer Bank: SOA als Grundlage für «Composite Applications"​
Artikel Schweizer Bank: SOA als Grundlage für «Composite Applications"​Artikel Schweizer Bank: SOA als Grundlage für «Composite Applications"​
Artikel Schweizer Bank: SOA als Grundlage für «Composite Applications"​
 
PLM Open Hours - Cloud PLM und PLM Trends
PLM Open Hours - Cloud PLM und PLM TrendsPLM Open Hours - Cloud PLM und PLM Trends
PLM Open Hours - Cloud PLM und PLM Trends
 
CLOUDSERVICES FÜR ISVs
CLOUDSERVICES FÜR ISVsCLOUDSERVICES FÜR ISVs
CLOUDSERVICES FÜR ISVs
 
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
 
Innovations- und Informationskultur mit Web 2.0 (2010)
Innovations- und Informationskultur mit Web 2.0 (2010)Innovations- und Informationskultur mit Web 2.0 (2010)
Innovations- und Informationskultur mit Web 2.0 (2010)
 
Microservices – die Architektur für Agile-Entwicklung?
Microservices – die Architektur für Agile-Entwicklung?Microservices – die Architektur für Agile-Entwicklung?
Microservices – die Architektur für Agile-Entwicklung?
 
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdfDACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
 
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
 
00 Einleitung und Übersicht zur COMLINE Cloud Service Plattform - CSP
00 Einleitung und Übersicht zur COMLINE Cloud Service Plattform - CSP00 Einleitung und Übersicht zur COMLINE Cloud Service Plattform - CSP
00 Einleitung und Übersicht zur COMLINE Cloud Service Plattform - CSP
 
Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...
Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...
Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...
 
Der erste Schritt – idealtypische Wege in die Cloud und in der Cloud für Unte...
Der erste Schritt – idealtypische Wege in die Cloud und in der Cloud für Unte...Der erste Schritt – idealtypische Wege in die Cloud und in der Cloud für Unte...
Der erste Schritt – idealtypische Wege in die Cloud und in der Cloud für Unte...
 
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
 
Modulare Enterprise Systeme - Eine Einführung
Modulare Enterprise Systeme - Eine EinführungModulare Enterprise Systeme - Eine Einführung
Modulare Enterprise Systeme - Eine Einführung
 
Steinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionSteinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen Evolution
 
onSelect
onSelectonSelect
onSelect
 
Micro, Nano, Mono - Microservices verständlich erklärt.
Micro, Nano, Mono  - Microservices verständlich erklärt.Micro, Nano, Mono  - Microservices verständlich erklärt.
Micro, Nano, Mono - Microservices verständlich erklärt.
 
Steinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionSteinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen Evolution
 

Mehr von Brockhaus Consulting GmbH

Industrie 40 Symposium an der RFH Köln 7.7.2016
Industrie 40 Symposium an der RFH Köln 7.7.2016 Industrie 40 Symposium an der RFH Köln 7.7.2016
Industrie 40 Symposium an der RFH Köln 7.7.2016 Brockhaus Consulting GmbH
 
Java EE Pattern: Entity Control Boundary Pattern and Java EE
Java EE Pattern: Entity Control Boundary Pattern and Java EEJava EE Pattern: Entity Control Boundary Pattern and Java EE
Java EE Pattern: Entity Control Boundary Pattern and Java EEBrockhaus Consulting GmbH
 

Mehr von Brockhaus Consulting GmbH (20)

Industrie 40 Symposium an der RFH Köln 7.7.2016
Industrie 40 Symposium an der RFH Köln 7.7.2016 Industrie 40 Symposium an der RFH Köln 7.7.2016
Industrie 40 Symposium an der RFH Köln 7.7.2016
 
Zeitreihen in Apache Cassandra
Zeitreihen in Apache CassandraZeitreihen in Apache Cassandra
Zeitreihen in Apache Cassandra
 
M2M infrastructure using Docker
M2M infrastructure using DockerM2M infrastructure using Docker
M2M infrastructure using Docker
 
Arquillian in a nutshell
Arquillian in a nutshellArquillian in a nutshell
Arquillian in a nutshell
 
Big Data and Business Intelligence
Big Data and Business IntelligenceBig Data and Business Intelligence
Big Data and Business Intelligence
 
OPC -Connectivity using Java
OPC -Connectivity using JavaOPC -Connectivity using Java
OPC -Connectivity using Java
 
Mobile Endgeräte in der Produktion
Mobile Endgeräte in der ProduktionMobile Endgeräte in der Produktion
Mobile Endgeräte in der Produktion
 
Intro 2 Machine Learning
Intro 2 Machine LearningIntro 2 Machine Learning
Intro 2 Machine Learning
 
Messaging im Internet of Things: MQTT
Messaging im Internet of Things: MQTTMessaging im Internet of Things: MQTT
Messaging im Internet of Things: MQTT
 
Industrie 4.0: Symposium an der RFH Köln
Industrie 4.0: Symposium an der RFH KölnIndustrie 4.0: Symposium an der RFH Köln
Industrie 4.0: Symposium an der RFH Köln
 
Java EE Pattern: Infrastructure
Java EE Pattern: InfrastructureJava EE Pattern: Infrastructure
Java EE Pattern: Infrastructure
 
Java EE Pattern: The Entity Layer
Java EE Pattern: The Entity LayerJava EE Pattern: The Entity Layer
Java EE Pattern: The Entity Layer
 
Java EE Pattern: The Control Layer
Java EE Pattern: The Control LayerJava EE Pattern: The Control Layer
Java EE Pattern: The Control Layer
 
Java EE Pattern: The Boundary Layer
Java EE Pattern: The Boundary LayerJava EE Pattern: The Boundary Layer
Java EE Pattern: The Boundary Layer
 
Java EE Pattern: Entity Control Boundary Pattern and Java EE
Java EE Pattern: Entity Control Boundary Pattern and Java EEJava EE Pattern: Entity Control Boundary Pattern and Java EE
Java EE Pattern: Entity Control Boundary Pattern and Java EE
 
Industry 4.0
Industry 4.0Industry 4.0
Industry 4.0
 
Big Data in Production Environments
Big Data in Production EnvironmentsBig Data in Production Environments
Big Data in Production Environments
 
BRO 110: Reference Architecture
BRO 110: Reference ArchitectureBRO 110: Reference Architecture
BRO 110: Reference Architecture
 
Architekturbewertung
ArchitekturbewertungArchitekturbewertung
Architekturbewertung
 
Bro110 5 1_software_architecture
Bro110 5 1_software_architectureBro110 5 1_software_architecture
Bro110 5 1_software_architecture
 

Microservices und das 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