SlideShare ist ein Scribd-Unternehmen logo
COMLINE Cloud Services
Architecture Design Patterns
Christian Günther
Hannover, 09.12.2016
Die COMLINE AG präsentiert
Software Architecture Design Patterns
Die Anwendungen auf einer Cloud Service Plattform
werden entlang der folgenden Entwurfsmuster
konzipiert:
1. Domain Driven Design
2. Microservices Architektur
3. Hexagonale Architektur
4. Peer-to-Peer Architektur
5. Nachrichtenbasiertes System
6. CQRS
Durch diese Entwurfsmuster wird eine Software-
Architektur geschaffen, welche elastisch ist und
verteilt arbeitet. Die entspricht damit den Prinzipien
und Konzepten für eine Cloud Service Umgebung
und bietet in dieser Laufzeitumgebung optimalen
nutzen.
Entwurfsmuster sind bewährte
Lösungsschablonen für
wiederkehrende Entwurfsprobleme.
Software Architecture Design Patterns
Domain Driven Design beschreibt eine
Methode zur Modellierung komplexer,
objektorientierter Software
 Im Grundsatz geht das Domain Driven
Design von 2 Annahmen aus:
1. Der Sinn jeder Software ist es, die
Aufgabenstellungen einer bestimmten
Anwendungsdomäne zu unterstützen.
2. Die SW-technische Umsetzung, insbesondere
Datenmodell und Serviceschnitt, muss sich
entsprechend nach dem Fachmodell richten.
 Erreicht wird dies, indem die Software
grundlegende Konzepte und Elemente der
Anwendungsdomäne, sowie deren
Beziehungen modelliert.
Das Domain Driven Design ist ein
abstraktes Modell zum Design einer
Anwendung basierend auf ihrem
Fachmodell
Domain Driven Design
 Beim DDD wird von einer Gliederung der Software in ein Schichtenmodell
ausgegangen und das Hauptaugenmerk liegt dabei auf der
Geschäftslogikschicht.
 Die Klassen des Fachmodells enthalten im Domain-Driven Design sowohl
die Daten als auch die gesamte Funktionalität der umzusetzenden
Fachlichkeit, also die gesamte Fachlogik.
 Der Ansatz orientiert sich, obwohl nicht an ein Vorgehensmodell gebunden,
an agilen Methoden und setzt dabei auf iterative Entwicklungsschritte und
eine enge Zusammenarbeit zwischen Entwickler und Fachbereich.
Domain Driven Design
 Entitäten (Entities) repräsentieren identifizierbare, elementare Konzepte
des Fachmodell und ihre Eigenschaften – z.B. ein Fahrzeug.
 Wertobjekte (Value objects) besitzen keine eigene Identität, sondern
werden nur durch ihre Eigenschaften definiert.
 Aggregate (Aggregates) fassen Entitäten zu einer Klasse zusammen.
 Assoziationen (Associations) stellen Beziehungen zwischen Objekten dar
 Serviceobjekte (Services) repräsentieren eine Fachlichkeit, welche zu
mehreren Objekten gehört.
 Fachliche Ereignisse (Domain Events) bewirken welche Änderungen an
den Fachobjekten.
 Module (Packages) teilen das Fachmodell in einzelne, nicht technische
Einheiten.
 Fabriken (Factories) dienen der Erzeugung eines Fachobjektes, wenn
dieses komplexer Natur ist und z.B. Assoziationen enthält.
 Repositories abstrahieren die Ablage und Suche nach Fachobjekten.
Elemente des Domain Driven Design
Microservices-Architektur
In einer monolithischen Anwendung
sind alle Funktionen in einem Prozess
Skalierung ist nur durch die Replikation
auf mehrere Server erreichbar
In einer Microservice Architektur ist
jede Funktion ein separater, einzeln
lauffähiger Service
Skalierung wird durch die Distribution
dieser Services über Server- und
Datacentergrenzen hinweg erreicht
 Als Microservices-Architecture wird ein
Architekturansatz bezeichnet, bei dem die
Funktionen einer Software in extrem kleine
Dienste geschnitten werden.
 Diese Dienste erfüllen dabei typischerweise
exakt einen Anwendungsfall und können
voneinander unabhängig verteilt und auch
weiterentwickelt werden.
 Die Services werden von unabhängigen
Teams gemäß fachlicher Anforderung
entwickelt und erfüllen exakt nur diese
Anforderung.
Microservices-Architektur
Microservices sind soweit
entkoppelt (voneinander
unabhängig), dass sie sich völlig
individuell weiterentwickeln können.
Microservices und SOA
 Microservices und SOA ähneln sich in vielen Belangen.
 Beide Architekturstile schneiden Funktionen in Dienste, welche dann zu
einer Anwendung zusammengesetzt werden.
 Der Unterschied liegt entsprechend eher in der menschlichen Sprache, als
der Technologie.
 Wann immer man von SOA spricht, wird meist eine Architektur mit einem
zentralen Service-Bus gemeint. In diesem werden die Dienste zur Nutzung
durch andere Layer bereitgestellt und häufig auch orchestriert.
 Microservices erwarten keine solche Komponente. Sie können zwar in einer
Service-Map zur Nutzung dokumentiert werden, setzen aber in aller Regel
einfach auf einen Applikationsserver auf.
 Microservices bieten eine dokumentierte Schnittstelle (etwa eine API) an,
über die sie von anderen Diensten oder auch Oberflächen genutzt werden
können.
Microservices vs. SOA
Hexagonale Architektur / Ports und Adapter
In einer hexagonalen Architektur
kann eine Funktion aus dem
Domain Modell (ein Service etwa)
über einen beliebigen Adapter
angesprochen werden
Ports verknüpfen die Adapter
(manchmal auch Mediator
genannt) mit spezifischen,
technischen Systemen
Im Kern der Architektur steht das
Modell der Anwendungsdomäne,
also Services welche de Business
Logik repräsentieren
Voice
 Hexagonale Architektur
– Strikte Trennung von Daten / Logik / Funktion und UI
– Jede Funktion/Logik kann über ein beliebiges
Interface angesprochen werden
– Ein Interface kann eine Benutzeroberfläche, eine
Systemschnittstelle oder sogar eine Spracheingabe
sein.
Hexagonal Architecture / Ports und Adapter
 In einem Peer-to-Peer-Netz sind alle
Computer gleichberechtigt und können
sowohl Dienste in Anspruch nehmen, als
auch zur Verfügung stellen.
 Mittels Lookup-Operation können Peers im
Netzwerk diejenigen Peers identifizieren,
welche für eine bestimmte Objektkennung
(Object-ID) zuständig sind.
 PTP-Systeme besitzen keinen Master und
benötigen damit auch keine teuren
Hochverfügbarkeitsmechanismen.
 PTP-Systeme sind (theoretisch) unendlich
horizontal skalierbar und können
entsprechend gut für bei Anforderungen
aus dem Web- oder BigData-Bereich
eingesetzt werden.
Visualisierung eines Peer-to-Peer
Netzwerkes
Peer-to-Peer Architecture
 Bei einer Event Driven Architecture wird
das Zusammenspiel der Komponenten
durch Ereignisse gesteuert.
 Ereignisse können dabei sowohl Trigger,
als auch Nachrichten sein – im letzten Fall
spricht man auch von einer
nachrichtenbasierten Architektur.
 Ein Ereignis umfasst meist drei Angaben:
den Erstellungszeitpunkt, die auslösende
Komponente (Quelle) und die Art des
Ereignisses (Typ), die angibt, was im
Wesentlichen vorgefallen ist.
 Aufgeteilt wird die Software dabei in
Ereignis-Produzenten, den Channel, das
Ereignis-Regelwerk (Engine) und die
verarbeitenden Clients.
Events werden vom Event-Listener
an die Event Engine übergeben, die
diese an Clients verteilt.
Event Driven Architecture (Nachrichtenbasiert)
 Trennung der Verantwortung von Software-
Komponenten, je nachdem, ob sie für
schreibende oder lesende Operationen genutzt
werden.
 Gegenentwurf zum klassischen CRUD – Create,
Read, Update Delete.
 Commands sollen, möglichst kleine, Teile von
Daten schreiben.
 Queries sollen möglichst große Mengen an
Daten auf einmal lesen.
 CQRS kann in unterschiedlichen
Architekturmustern eingesetzt werden, eignet
sich aber insbesondere mit der Nutzung einer
Document Database, wie MongoDB.
CQRS setzt auf einem Domain-
Modell auf und verteilt die Workload
für lesende und schreibene Arbeiten
auf zwei getrennte Arbeitsbereiche
in der Software
CQRS Command Query Responsibility Segregation
Christian Günther
Principal Solution Architect
Mobile: +49 1511 22 40 942
E-Mail: christian.guenther@comlineag.de
COMLINE Computer und Softwarelösungen AG
Leverkusenstr. 54
DE - 22761 Hamburg
www.comlineag.de
Vielen Dank für Ihre Aufmerksamkeit.

Weitere ähnliche Inhalte

Andere mochten auch

Mia software mdday2010
Mia software mdday2010Mia software mdday2010
Mia software mdday2010
MD DAY
 
Das Potential von Open Source Software nutzen und die Risiken minimieren
Das Potential von Open Source Software nutzen und die Risiken minimierenDas Potential von Open Source Software nutzen und die Risiken minimieren
Das Potential von Open Source Software nutzen und die Risiken minimieren
Matthias Stürmer
 
Exibri Software Product Lines Aosd
Exibri Software Product Lines AosdExibri Software Product Lines Aosd
Exibri Software Product Lines Aosd
Cédric WILLIAMSON
 
Social Software Im Unternehmen
Social Software Im UnternehmenSocial Software Im Unternehmen
Social Software Im Unternehmen
Helmut Nagy
 

Andere mochten auch (20)

Torsten Grote: Freie Software
Torsten Grote: Freie SoftwareTorsten Grote: Freie Software
Torsten Grote: Freie Software
 
Einsatz von Social Software für Online-Marketing und virtuelle Zusammenarbeit...
Einsatz von Social Software fürOnline-Marketing und virtuelle Zusammenarbeit...Einsatz von Social Software fürOnline-Marketing und virtuelle Zusammenarbeit...
Einsatz von Social Software für Online-Marketing und virtuelle Zusammenarbeit...
 
Blogwerk: Content Marketing an der SuisseEMEX 2013
Blogwerk: Content Marketing an der SuisseEMEX 2013Blogwerk: Content Marketing an der SuisseEMEX 2013
Blogwerk: Content Marketing an der SuisseEMEX 2013
 
(In)Segurança De Software, Quebrando Códigos
(In)Segurança De Software, Quebrando Códigos(In)Segurança De Software, Quebrando Códigos
(In)Segurança De Software, Quebrando Códigos
 
Mia software mdday2010
Mia software mdday2010Mia software mdday2010
Mia software mdday2010
 
Das Potential von Open Source Software nutzen und die Risiken minimieren
Das Potential von Open Source Software nutzen und die Risiken minimierenDas Potential von Open Source Software nutzen und die Risiken minimieren
Das Potential von Open Source Software nutzen und die Risiken minimieren
 
Software Academy 10 Erreurs Rh Par Altaide Et Moovement
Software Academy 10 Erreurs Rh Par Altaide Et MoovementSoftware Academy 10 Erreurs Rh Par Altaide Et Moovement
Software Academy 10 Erreurs Rh Par Altaide Et Moovement
 
Lm software
Lm softwareLm software
Lm software
 
Open Source Software: Reif für den typischen CH KMU?
Open Source Software: Reif für den typischen CH KMU?Open Source Software: Reif für den typischen CH KMU?
Open Source Software: Reif für den typischen CH KMU?
 
Slide Lewis Chimarro
Slide   Lewis ChimarroSlide   Lewis Chimarro
Slide Lewis Chimarro
 
Solutions en mode SaaS (Software as a Service) : les PME accèdent-elles à des...
Solutions en mode SaaS (Software as a Service) : les PME accèdent-elles à des...Solutions en mode SaaS (Software as a Service) : les PME accèdent-elles à des...
Solutions en mode SaaS (Software as a Service) : les PME accèdent-elles à des...
 
Wertstoff Software - Wissenssicherung in Legacy-Systemen
Wertstoff Software - Wissenssicherung in Legacy-SystemenWertstoff Software - Wissenssicherung in Legacy-Systemen
Wertstoff Software - Wissenssicherung in Legacy-Systemen
 
Exibri Software Product Lines Aosd
Exibri Software Product Lines AosdExibri Software Product Lines Aosd
Exibri Software Product Lines Aosd
 
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-ToolsSoftware-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
 
Freie Software in der (Groß-)Forschung
Freie Software in der (Groß-)ForschungFreie Software in der (Groß-)Forschung
Freie Software in der (Groß-)Forschung
 
2009 Wikimanagement: Neue Denkansätze für die Wissensnutzung im Geschäftsproz...
2009 Wikimanagement: Neue Denkansätze für die Wissensnutzung im Geschäftsproz...2009 Wikimanagement: Neue Denkansätze für die Wissensnutzung im Geschäftsproz...
2009 Wikimanagement: Neue Denkansätze für die Wissensnutzung im Geschäftsproz...
 
Social Software Im Unternehmen
Social Software Im UnternehmenSocial Software Im Unternehmen
Social Software Im Unternehmen
 
Präsentation PM Forum - Social Software
Präsentation PM Forum  - Social SoftwarePräsentation PM Forum  - Social Software
Präsentation PM Forum - Social Software
 
Arcsys software - Le coffre fort numérique
Arcsys software - Le coffre fort numériqueArcsys software - Le coffre fort numérique
Arcsys software - Le coffre fort numérique
 
Testen von Software (german)
Testen von Software (german)Testen von Software (german)
Testen von Software (german)
 

Ähnlich wie Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP

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
Christian Guenther
 
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
 
Adruni Ishan Unified Workplace V2
Adruni Ishan   Unified Workplace V2Adruni Ishan   Unified Workplace V2
Adruni Ishan Unified Workplace V2
Adruni Ishan
 

Ähnlich wie Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP (20)

Microservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary PatternMicroservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary Pattern
 
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
 
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
 
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?
 
Pragmatic SOA - Beschränken auf das Wesentliche
Pragmatic SOA - Beschränken auf das WesentlichePragmatic SOA - Beschränken auf das Wesentliche
Pragmatic SOA - Beschränken auf das Wesentliche
 
Cloud Ready? Migration von Anwendungen in die Cloud
Cloud Ready? Migration von Anwendungen in die CloudCloud Ready? Migration von Anwendungen in die Cloud
Cloud Ready? Migration von Anwendungen in die Cloud
 
Modulare Enterprise Systeme - Eine Einführung
Modulare Enterprise Systeme - Eine EinführungModulare Enterprise Systeme - Eine Einführung
Modulare Enterprise Systeme - Eine Einführung
 
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...
 
TRANSCONNECT® cloud (SQL Projekt AG)
TRANSCONNECT® cloud (SQL Projekt AG)TRANSCONNECT® cloud (SQL Projekt AG)
TRANSCONNECT® cloud (SQL Projekt AG)
 
OSLC in Aktion
OSLC in AktionOSLC in Aktion
OSLC in Aktion
 
Produktblatt TRANSCONNECT - DE | SQL Projekt AG
Produktblatt TRANSCONNECT - DE | SQL Projekt AGProduktblatt TRANSCONNECT - DE | SQL Projekt AG
Produktblatt TRANSCONNECT - DE | SQL Projekt AG
 
Adruni Ishan Unified Workplace V2
Adruni Ishan   Unified Workplace V2Adruni Ishan   Unified Workplace V2
Adruni Ishan Unified Workplace V2
 
Cloud Computing - Technische Grundlagen, Chancen und Probleme des Trends
Cloud Computing - Technische Grundlagen, Chancen und Probleme des TrendsCloud Computing - Technische Grundlagen, Chancen und Probleme des Trends
Cloud Computing - Technische Grundlagen, Chancen und Probleme des Trends
 
MEAN SCS in der Cloud
MEAN SCS in der CloudMEAN SCS in der Cloud
MEAN SCS in der Cloud
 
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
 
Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...
Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...
Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...
 
UnifiedSessionsManager - Virtualisierung und Cloud-Computing
UnifiedSessionsManager - Virtualisierung und Cloud-ComputingUnifiedSessionsManager - Virtualisierung und Cloud-Computing
UnifiedSessionsManager - Virtualisierung und Cloud-Computing
 
BATbern41 Die Evolution zu Microservices
BATbern41 Die Evolution zu MicroservicesBATbern41 Die Evolution zu Microservices
BATbern41 Die Evolution zu Microservices
 
Open Cloud Alliance - Quo Vadis? - Univention Summit 2016
Open Cloud Alliance - Quo Vadis? - Univention Summit 2016Open Cloud Alliance - Quo Vadis? - Univention Summit 2016
Open Cloud Alliance - Quo Vadis? - Univention Summit 2016
 
Microservices - Was EAs zu Microservices wissen sollten
Microservices - Was EAs zu Microservices wissen solltenMicroservices - Was EAs zu Microservices wissen sollten
Microservices - Was EAs zu Microservices wissen sollten
 

Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP

  • 1. COMLINE Cloud Services Architecture Design Patterns Christian Günther Hannover, 09.12.2016 Die COMLINE AG präsentiert
  • 3. Die Anwendungen auf einer Cloud Service Plattform werden entlang der folgenden Entwurfsmuster konzipiert: 1. Domain Driven Design 2. Microservices Architektur 3. Hexagonale Architektur 4. Peer-to-Peer Architektur 5. Nachrichtenbasiertes System 6. CQRS Durch diese Entwurfsmuster wird eine Software- Architektur geschaffen, welche elastisch ist und verteilt arbeitet. Die entspricht damit den Prinzipien und Konzepten für eine Cloud Service Umgebung und bietet in dieser Laufzeitumgebung optimalen nutzen. Entwurfsmuster sind bewährte Lösungsschablonen für wiederkehrende Entwurfsprobleme. Software Architecture Design Patterns
  • 4. Domain Driven Design beschreibt eine Methode zur Modellierung komplexer, objektorientierter Software  Im Grundsatz geht das Domain Driven Design von 2 Annahmen aus: 1. Der Sinn jeder Software ist es, die Aufgabenstellungen einer bestimmten Anwendungsdomäne zu unterstützen. 2. Die SW-technische Umsetzung, insbesondere Datenmodell und Serviceschnitt, muss sich entsprechend nach dem Fachmodell richten.  Erreicht wird dies, indem die Software grundlegende Konzepte und Elemente der Anwendungsdomäne, sowie deren Beziehungen modelliert. Das Domain Driven Design ist ein abstraktes Modell zum Design einer Anwendung basierend auf ihrem Fachmodell Domain Driven Design
  • 5.  Beim DDD wird von einer Gliederung der Software in ein Schichtenmodell ausgegangen und das Hauptaugenmerk liegt dabei auf der Geschäftslogikschicht.  Die Klassen des Fachmodells enthalten im Domain-Driven Design sowohl die Daten als auch die gesamte Funktionalität der umzusetzenden Fachlichkeit, also die gesamte Fachlogik.  Der Ansatz orientiert sich, obwohl nicht an ein Vorgehensmodell gebunden, an agilen Methoden und setzt dabei auf iterative Entwicklungsschritte und eine enge Zusammenarbeit zwischen Entwickler und Fachbereich. Domain Driven Design
  • 6.  Entitäten (Entities) repräsentieren identifizierbare, elementare Konzepte des Fachmodell und ihre Eigenschaften – z.B. ein Fahrzeug.  Wertobjekte (Value objects) besitzen keine eigene Identität, sondern werden nur durch ihre Eigenschaften definiert.  Aggregate (Aggregates) fassen Entitäten zu einer Klasse zusammen.  Assoziationen (Associations) stellen Beziehungen zwischen Objekten dar  Serviceobjekte (Services) repräsentieren eine Fachlichkeit, welche zu mehreren Objekten gehört.  Fachliche Ereignisse (Domain Events) bewirken welche Änderungen an den Fachobjekten.  Module (Packages) teilen das Fachmodell in einzelne, nicht technische Einheiten.  Fabriken (Factories) dienen der Erzeugung eines Fachobjektes, wenn dieses komplexer Natur ist und z.B. Assoziationen enthält.  Repositories abstrahieren die Ablage und Suche nach Fachobjekten. Elemente des Domain Driven Design
  • 7. Microservices-Architektur In einer monolithischen Anwendung sind alle Funktionen in einem Prozess Skalierung ist nur durch die Replikation auf mehrere Server erreichbar In einer Microservice Architektur ist jede Funktion ein separater, einzeln lauffähiger Service Skalierung wird durch die Distribution dieser Services über Server- und Datacentergrenzen hinweg erreicht
  • 8.  Als Microservices-Architecture wird ein Architekturansatz bezeichnet, bei dem die Funktionen einer Software in extrem kleine Dienste geschnitten werden.  Diese Dienste erfüllen dabei typischerweise exakt einen Anwendungsfall und können voneinander unabhängig verteilt und auch weiterentwickelt werden.  Die Services werden von unabhängigen Teams gemäß fachlicher Anforderung entwickelt und erfüllen exakt nur diese Anforderung. Microservices-Architektur Microservices sind soweit entkoppelt (voneinander unabhängig), dass sie sich völlig individuell weiterentwickeln können.
  • 10.  Microservices und SOA ähneln sich in vielen Belangen.  Beide Architekturstile schneiden Funktionen in Dienste, welche dann zu einer Anwendung zusammengesetzt werden.  Der Unterschied liegt entsprechend eher in der menschlichen Sprache, als der Technologie.  Wann immer man von SOA spricht, wird meist eine Architektur mit einem zentralen Service-Bus gemeint. In diesem werden die Dienste zur Nutzung durch andere Layer bereitgestellt und häufig auch orchestriert.  Microservices erwarten keine solche Komponente. Sie können zwar in einer Service-Map zur Nutzung dokumentiert werden, setzen aber in aller Regel einfach auf einen Applikationsserver auf.  Microservices bieten eine dokumentierte Schnittstelle (etwa eine API) an, über die sie von anderen Diensten oder auch Oberflächen genutzt werden können. Microservices vs. SOA
  • 11. Hexagonale Architektur / Ports und Adapter In einer hexagonalen Architektur kann eine Funktion aus dem Domain Modell (ein Service etwa) über einen beliebigen Adapter angesprochen werden Ports verknüpfen die Adapter (manchmal auch Mediator genannt) mit spezifischen, technischen Systemen Im Kern der Architektur steht das Modell der Anwendungsdomäne, also Services welche de Business Logik repräsentieren Voice
  • 12.  Hexagonale Architektur – Strikte Trennung von Daten / Logik / Funktion und UI – Jede Funktion/Logik kann über ein beliebiges Interface angesprochen werden – Ein Interface kann eine Benutzeroberfläche, eine Systemschnittstelle oder sogar eine Spracheingabe sein. Hexagonal Architecture / Ports und Adapter
  • 13.  In einem Peer-to-Peer-Netz sind alle Computer gleichberechtigt und können sowohl Dienste in Anspruch nehmen, als auch zur Verfügung stellen.  Mittels Lookup-Operation können Peers im Netzwerk diejenigen Peers identifizieren, welche für eine bestimmte Objektkennung (Object-ID) zuständig sind.  PTP-Systeme besitzen keinen Master und benötigen damit auch keine teuren Hochverfügbarkeitsmechanismen.  PTP-Systeme sind (theoretisch) unendlich horizontal skalierbar und können entsprechend gut für bei Anforderungen aus dem Web- oder BigData-Bereich eingesetzt werden. Visualisierung eines Peer-to-Peer Netzwerkes Peer-to-Peer Architecture
  • 14.  Bei einer Event Driven Architecture wird das Zusammenspiel der Komponenten durch Ereignisse gesteuert.  Ereignisse können dabei sowohl Trigger, als auch Nachrichten sein – im letzten Fall spricht man auch von einer nachrichtenbasierten Architektur.  Ein Ereignis umfasst meist drei Angaben: den Erstellungszeitpunkt, die auslösende Komponente (Quelle) und die Art des Ereignisses (Typ), die angibt, was im Wesentlichen vorgefallen ist.  Aufgeteilt wird die Software dabei in Ereignis-Produzenten, den Channel, das Ereignis-Regelwerk (Engine) und die verarbeitenden Clients. Events werden vom Event-Listener an die Event Engine übergeben, die diese an Clients verteilt. Event Driven Architecture (Nachrichtenbasiert)
  • 15.  Trennung der Verantwortung von Software- Komponenten, je nachdem, ob sie für schreibende oder lesende Operationen genutzt werden.  Gegenentwurf zum klassischen CRUD – Create, Read, Update Delete.  Commands sollen, möglichst kleine, Teile von Daten schreiben.  Queries sollen möglichst große Mengen an Daten auf einmal lesen.  CQRS kann in unterschiedlichen Architekturmustern eingesetzt werden, eignet sich aber insbesondere mit der Nutzung einer Document Database, wie MongoDB. CQRS setzt auf einem Domain- Modell auf und verteilt die Workload für lesende und schreibene Arbeiten auf zwei getrennte Arbeitsbereiche in der Software CQRS Command Query Responsibility Segregation
  • 16. Christian Günther Principal Solution Architect Mobile: +49 1511 22 40 942 E-Mail: christian.guenther@comlineag.de COMLINE Computer und Softwarelösungen AG Leverkusenstr. 54 DE - 22761 Hamburg www.comlineag.de Vielen Dank für Ihre Aufmerksamkeit.