COMLINE Cloud ServicesArchitecture Design Patterns

Christian GüntherHannover, 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 Design2. Microservices Architektur3. Hexagonale Architektur4. Peer-to-Peer Architektur5. Nachrichtenbasiertes System6. 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

AVoiceA

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üntherPrincipal Solution Architect

Mobile: +49 1511 22 40 942E-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.