APPE

Monolithisches Design → nicht modularisiert = erodierter Code 

Monolithisches Deployment → saubere modularisierte Applikation

Bsp: Eine Mobile-App, welche intern aus zehn verschiedenen, sauberen Komponenten (oder Libraries) besteht, kann problemlos als "monolithisches" Packet (am Stück) verteilt werden.

Die Grösse → Es ist ein KlumpenrisikoBei kleinen Änderungen muss die ganze Anwendung neu deployed werden.

Bei verteilten Applikationen werden einzelne Teile, Teilsysteme, Komponenten, Module, Schichten etc. auf mehrere verschiedenen Rechner (Hosts, Tiers) verteilt. Konsequenzen:

• Die Teile laufen in einzelnen unabhängigen Prozessen
• Die Teile laufen in echter Parallelität (TIERS -> verteilt auf auf verschiedenen Systemen)

Anforderungen:

• Kommunikation untereinander
• Softwareteile müssen sich finden und kennen
• Deployment wird aufwendiger
• Es muss mit (Teil-)Ausfällen umgegangen werden können

Mit der Modularisierung möchte man sinnvolle funktionale Module und möglichst abgeschlossenen Einheiten bilden. Dabei verfügen sie über wohldefinierte Schnittstellen. Dies führt zur…

• einer besseren Verständlichkeit
• paralleler Entwicklungsmöglichkeit
• Wiederverwendbarkeit

• Kopplung → Ausmass der Kommunikation und Abhängigkeit zwischen den Modulen
• Kohäsion → Ausmass der Kommunikation und interner Zusammenhalt innerhalb eines Moduls

Kopplung und Kohäsion werden auf allen Abstraktionsebenen immer wieder neu beurteilt. Anforderungen werde jedoch zunehmend strenger.

Übergeordnete Struktur in der Architektur

• Gruppierung → Eine Menge von Modulen mit gemeinsamen Eigenschaften wird als Gruppe gehandhabt.
• Hierarchie → Ein Modul fasst eine Gruppe von (Sub-)Modulen zu einem einzigen zusammen.
• Geschichtet → Modul(-gruppen) können eine logische Kette bilden, die vertikal meist als Schichten betrachtetet werden.

• Explizite Schnittstelle
• Starke Kohäsion
• Daraus ergibt sich → Information Hidding & Lose Kopplung

Kriterien für den Entwurf eines Modules. Die vier fundamentalen Kriterien sind:

• Zerlegbarkeit → Module sind möglichst unabhängig voneinander
• Kombinierbarkeit → Flexibel und kombinierbar
• Verständlichkeit → Einzeln und ohne (wenig) Kontext verständlich
• Stetigkeit / Kontinuität → Module haben Beständigkeit

• REP → Reuse-Release-Equivalence Prinzip (man fügt das zusammen, was in einer version auch deployd wird)
• CCP →Common-Closure Prinzip (SRP & OCP auf Architekturebene)
• CRP → Common-Reuse Prinzip (keine unnötigen Abhängigkeiten)

• ADP → Acyclic Dependencies Prinzip (zyklische Abhängigkeiten sind nicht erlaubt)
• SDP → Stable Dependencies Prinzip (Abhängigkeit in Richtung der stabilen Komponente)
• SAP → Stable Abstractions Prinzip (Damit Ihre Stabilität nicht verhindert, damit sie erweitert werden können.)

Granularität der Wiederverwendung ist eine Granularität des Releases.→ Man fügt das zusammen was auch gemeinsam (mit einer Version) veröffentlicht wird. → REP ist ein inkludierendes Prinzip.

Klassen die aus denselben Gründen und zur selben Zeit modifiziert werden, fasst man in den selben Komponenten zusammen. Das ist nichts anderes als SRP (Single Responsibility Prinzip) und OCP (Open Closed Prinzip) auf Architekturebene angewendet.CCP ist ein inkludierendes Prinzip.

Zwinge den Nutzer einer Komponente nicht in eine Abhängigkeit von Elementen die er nicht benötigt.→ Ein Modul sollte nur als Ganzes sinnvoll nutzbar sein und nicht nur Teile oder Bruchstücke davon.

Zwischen Komponenten sind keine Zyklen erlaubt -> lösung: Observer Pattern

Bsp. Observer Pattern:

Die Abhängigkeit der Komponenten sollte in Richtung der Stabilern Komponente verlaufen.Stabil = schwer veränderbar

Stabile Komponenten sollten im gleichen Masse auch abstrakt sein. Damit Ihre Stabilität nicht verhindert, damit sie erweitert werden können.

• Architekturmuster → Beschreiben als Konzept den Grundaufbau eines ganzen Systems
• Entwurfsmuster → objektorientierte Konzepte für Teilprobleme

Architekturmuster werden für verschiedene zentrale Aspekte benötigt.Um grosse, komplexe System zu strukturieren. Beispielsweise

• für stark verteilte Systeme
• für inter(re)aktive Systeme
• für hochverfügbare Systeme

Gliederung eines Systems in aufeinander aufbauende, funktionale Schichten.

• Kommunikation über wohldefinierte Schnittstellen.
• Abhängigkeit nur in Richtung der tieferen Schicht.

Wird benötigt zur Strukturierung sowohl innerhalb eines Systems als auch Systemübergreifend. Bei möglicher physischer Verteilung der einzelnen Schichten spricht man von Tiers.

Kann nach verschiedenen Kriterien erfolgen:

• Logisch/ funktional
• Technik
• Abstraktionsebenen

Kann hierarchisch verfeinert werden:

• Funktionale Schichtung
• Nach Abstraktionslevel
• Nach Technologie / Sprache / Framework

Bei einer Implementation mit Java manifestieren sich die verschiedenen Schichten häufig als Packagestruktur:

• ch.domain.system.client.*
• ch.domain.system.server.*

Es empfiehlt sich feingranularer zu arbeiten.

wenn sich die Komponenten auf verschiedenen Rechnern befinden (physische trennung von schichten)

Aufteilung in drei fundamentale Schichten:

1. Präsentation Visualisierung, User Interface, UI-Logik

2. Geschäftslogik Implementation der Geschäftsprozesse und Modelle

3. Datenhaltung Persistente Datenspeicherung, Datenlogik

Aus der Verfeinerung einer 3-Schichten-Architektur kann folgende 6-Schicht-Architektur entstehen:

• Bessere Strukturierung
• Grössere Chance auf Wiederverwendung
• Hohe Flexibilität 
• Bessere Skalierbarkeit
• Einfachere und präzisere Planung
• Parallele und getrennte Entwicklung möglich

• Komplexität des ganzen Systems grösser
• Mehr Schnittstellen, mehr Aufwand, mehr Planung

Nicht die Anzahl (oder Höhe) der Schichten ist die Herausforderung, sondern zu erkennen, wann eine Schicht bzw. ein ganzer Stack zu breit wird.D.h Die Domäne einer Applikation wird schlicht zu gross - Als Konsequenz werden die Schichten zu breit. Daher braucht es eine weitere Partitionierung → Services

1. Services sind fachlich orientiert und technologieneutral.
2. Services kapseln sauber abgegrenzte Sub-Domänen in eigenständige, verteilte Dienste (Services).
3. Die Services sind in einem Verzeichnisdienst eingebunden und werden dynamisch gesucht und gebunden.
4. Die Dienste können von einer übergeordneten Applikationen zur Realisierung eines Businessprozesses genutzt (orchestriert) werden.
5. Ein Service verfügt über eine wohl definierte Schnittstelle.

Zwei Applikationen (Domänen) benötigen teilweise dieselben Daten und beide möchten Master sein. → Resultiert in einer inakzeptablen zyklischen Abhängigkeit. Lösung: Die gemeinsamen Teile als Subdomäne in einen neuen Service X auslösen:

Bsp:Mausklick auf einen Button löst Event aus, auf welchen sich beliebige Klassen/Komponenten registrieren und somit darauf reagieren können. (Lose Kopplung - Empfänger und Sender müssen sich nicht kennen)

Bei SOA manifestieren sich die Abhängigkeiten (Kommunikation) zwischen den Services meistens in einer synchronen Kommunikation.

Bsp:
Die Lager-Applikation braucht bestimmte Artikeldaten in einer funktionalen Abhängigkeit → Ohne diese Info kann das Lager nicht arbeiten. Bei diesen Ereignissen sind Aktionen denkbar, die zwar erfolgen sollen aber auch asynchron zu einem späteren Zeitpunkt erledigt werden können. →Messages/ Events in Queues/Topics

Der Service wird noch kleiner geschnitten - Man unterteilt eine Domain(-model) in kleinere möglichst unabhängige Teildomänen) → bounded context

1. Eine Applikation wird aufgeteilt in mehrere, kleine Services.

• Die Applikation wird primär vertikal in mehrere, möglichst eigenständige Teile aufgeteilt.
• Sie sollten möglichst autark arbeiten können und auf eigenen Daten(-modelle) zurückgreifen.
• Die Teile sollten möglichst nicht direkt miteinander kommunizieren müssen, sondern werden über das GUI oder über den vorgelagerten Gateway orchestriert.

2. Jeder Service läuft in eigenem Prozess auf einer eigenen Plattform

• typisch in virtualisiertem Container
• Laufen in echter Parallelität als verteiltes System

3. Leichtgewichtige Kommunikation (meist Restfull/http/JSON)

• Sehr populär sind JSON basierend auf Rest Schnittstellen aufgrund ihrer Einfachheit sehr populär.
• Gute Akzeptanz im Operating
• bestehend Protokolle

4. Voneinander unabhängig deploybar (somit auch Realeasbar)

• MS sind eigenständige Projekte und Release-Einheiten
• Unabhängig Deploybar (Applikation muss mit Ausfällen umgehen können)

5. Automatisiertes Deployment(DevOps, PaaS, IaaS)

• Weitgehende Automatisierung ist ein MUSS-Feature

• Schneller
• kleiner
• unabhängig deploybar
• austauschbarer
• flexiblere Entwicklung ist möglich
• eigene Datenhaltung
• unterschiedliche Technologien
• unterschiedliche Plattformen
• unterschiedliche Sprachen
• Resilienz
• Releasing.

• Hohe Anforderungen an das Operating (DevOps ist ein Muss)!
• Höhere Gesamtkomplexität durch Asynchronität und Resilienz.
• Neue Herausforderung durch cross-cutting-concerns wie Sicherheit, Überwachung, Monitoring und Logging.