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...
Domain Driven Design beschreibt eine
Methode zur Modellierung komplexer,
objektorientierter Software
 Im Grundsatz geht d...
 Beim DDD wird von einer Gliederung der Software in ein Schichtenmodell
ausgegangen und das Hauptaugenmerk liegt dabei au...
 Entitäten (Entities) repräsentieren identifizierbare, elementare Konzepte
des Fachmodell und ihre Eigenschaften – z.B. e...
Microservices-Architektur
In einer monolithischen Anwendung
sind alle Funktionen in einem Prozess
Skalierung ist nur durch...
 Als Microservices-Architecture wird ein
Architekturansatz bezeichnet, bei dem die
Funktionen einer Software in extrem kl...
Microservices und SOA
 Microservices und SOA ähneln sich in vielen Belangen.
 Beide Architekturstile schneiden Funktionen in Dienste, welche d...
Hexagonale Architektur / Ports und Adapter
In einer hexagonalen Architektur
kann eine Funktion aus dem
Domain Modell (ein ...
 Hexagonale Architektur
– Strikte Trennung von Daten / Logik / Funktion und UI
– Jede Funktion/Logik kann über ein belieb...
 In einem Peer-to-Peer-Netz sind alle
Computer gleichberechtigt und können
sowohl Dienste in Anspruch nehmen, als
auch zu...
 Bei einer Event Driven Architecture wird
das Zusammenspiel der Komponenten
durch Ereignisse gesteuert.
 Ereignisse könn...
 Trennung der Verantwortung von Software-
Komponenten, je nachdem, ob sie für
schreibende oder lesende Operationen genutz...
Christian Günther
Principal Solution Architect
Mobile: +49 1511 22 40 942
E-Mail: christian.guenther@comlineag.de
COMLINE ...
Nächste SlideShare
Wird geladen in …5
×

Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP

241 Aufrufe

Veröffentlicht am

Software Architecture Design Patterns für Cloud Service Entwicklungen

Domain Principles für Cloud Services und Cloud Anwendungsentwicklung

In den letzten zehn bis fünfzehn Jahren haben sich eine Reihe von Architekturparadigmen etabliert, die heute die Grundlage für Unternehmensanwendungen definieren und in vielfältigen Standards, Frameworks und Best Practices so fest verankert sind, dass man kaum noch darüber nachdenkt.

Wendet man diese Paradigmen unreflektiert auf Cloud-Anwendungen an, führt das in der Regel zu ernüchternden Resultaten. Insbesondere die für Cloud Computing wichtigen Eigenschaften Skalierbarkeit, Elastizität und Robustheit sind auf diese Weise nicht erreichbar.

Ein Umdenken ist also notwendig, um die Potenziale der Cloud freizusetzen.

Die COMLINE Cloud Computing Platform (CSP) ist die Antwort hierauf, sie ist eine moderne Plattform für Cloud-Computing und wurde als reaktives System konzipiert.

Reaktive Systeme müssen stets antwortbereit, widerstandsfähig, elastisch und nachrichtenorientiert sein. Systeme und Plattformen, die nach diesen Anforderungen entwickelt werden, erweisen sich als anpassungsfähiger, mit weniger starr gekoppelten Komponenten und in jeder Hinsicht skalierbarer. Sie sind einfacher weiterzuentwickeln und zu verändern. Sie reagieren zuverlässiger und eleganter auf Fehler und vermeiden so desaströse Ausfälle. Reaktive Systeme bereiten dem Anwender durch ihre fortwährende Antwortfreudigkeit eine interaktive und höchst befriedigende Erfahrung.

All diese Anforderungen erfüllt die COMLINE Cloud Service Plattform.

Aus Sicht der COMLINE eine PaaS (Platform as a Service) dar, auf der COMLINE Cloud-Dienste entwickelt.
Betrieben wird die CSP auf einem IaaS Modell in COMLINE-eigenen Rechenzentren in Berlin
Die Cloud-Dienste werden zu Anwendungen zusammengefasst, die von Kunden der COMLINE im Sinne eines SaaS (Software as a Service) Modells gemietet und genutzt werden können.

Sowohl die Plattform selber, als auch die Services und Anwendungen werden entlang einer Reihe von Guidelines entwickelt und betrieben. Diese Guidelines bilden die Grundlage aller Aktivitäten (von Design, über Konzeption bis hin zu Entwicklung und Betrieb) auf der CSP

Die Folien auf Slideshare zeigen die Prinzipien, Paradigmen und Design Patterns auf, nach denen wir sowohl die CSP selber betreiben, als auch die Anwendungen auf ihr entwickeln und betreiben.

Die CSP wurde massgeblich von Christian Günther konzipiert und stellt heute die DeFacto Entwicklungsplattform für COMLINE dar.

Veröffentlicht in: Software
1 Kommentar
0 Gefällt mir
Statistik
Notizen
  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
241
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
0
Aktionen
Geteilt
0
Downloads
3
Kommentare
1
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP

  1. 1. COMLINE Cloud Services Architecture Design Patterns Christian Günther Hannover, 09.12.2016 Die COMLINE AG präsentiert
  2. 2. Software Architecture Design Patterns
  3. 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. 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. 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. 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. 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. 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.
  9. 9. Microservices und SOA
  10. 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. 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. 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. 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. 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. 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. 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.

×