APPE

• Jeder Service hat seine eigenen fachlichen Begrifflichkeiten
• Jeder Service kümmert sich selber um seine Persistierung
• Es ist kein konsistentes Datenmodell über die ganze Applikation notwendig
• Bei allfälligen Kommunikationen zwischen den Services müssen entsprechende Daten-Anpassungen gemacht werden.

• Die Services sind weitgehend unabhängig voneinander
• Auf fachlicher Ebenen muss kein Aufwand getrieben werden, um die Details der einzelnen Teildomänen miteinander abzugleichen.
• Unabhängig entwickelbar
• Unabhängig deploy- und releasebar
• Schneller
• kleiner
• unabhängiger
• austauschbarer
• flexibler
• eigene Datenhaltung
• unterschiedliche Technolgien (Sprachen)
• Plattformen
• Resilienz

• Technischer Overhead
• Technische Komplexität
• Zu kleine Microservices fördern den Kommunikationsbedarf. Die führt zu Mehraufwand in der Kommunikation und restlich zu einer Performance Beeinträchtigung.

• Man sieht das System mit seinen Grenzen
• Alle Akteure (d.h. Systemrelevante Umwelt)
• Alle Nachrichten (Informationsfluss) zwischen den Akteuren

Das Domänen-Modell (Fachmodell) beinhaltet alle Geschäftsobjekte (Business Entities) und ihre Beziehungen (Daten und Aktivitäten) einer Applikation.

Man zerlegt alle wesentlichen Prozesse einer Anwendung in ihre Teilschritte. Danach setzt man sie in ihre zeitliche Abfolge. Zudem sollten alle beteiligten Akteure eingezeichnet werden. Daraus wird ersichtlich, dass sich weitere Aufteilungen im beschränkten Kontext aufdrängen (bounded Context).

Im Use Case Diagramm werden sämtliche Use Cases / Anwendungsfälle und die Verbindungen zu den Akteuren aufgezeigt. Es empfiehlt sich mittels Pfeilen einzuzeichnen, wer die Use Cases anstösst.

Wikipedia:
«Ein Anwendungsfall (engl. use case) bündelt alle möglichen Szenarien, die eintreten können, wenn ein Akteur versucht, mit Hilfe des betrachteten Systems ein bestimmtes fachliches Ziel (engl. business goal) zu erreichen. Er beschreibt, was inhaltlich beim Versuch der Zielerreichung passieren kann und abstrahiert von konkreten technischen Lösungen.

Man stellt ein System in Teilblöcken dar. Hier wird gezeigt wie die einzelnen Teilblöcke miteinander interagieren via Input und Output-Signale.

Blockdiagramm
Mehrere Blöcke können zusammen neue Blöcke bilden.

Bild

Bild

Request / Response
Synchrone NAchricht, Sender erwartet eine Antwort, Nachricht wird konsumiert. (d.h. nur ein Empfänger)

Winner-take-all
Asnchrone NAchricht, Sender erwartetet keine Antwort. Nachricht wird konsumiert (d.h nur ein Empfänger)

Synchrone Nachricht die nicht konsumiert wird, d.h auch andere Empfänger können diese konsumieren. Sender erwartete zumindest eine Antwort.

Fire & Forget
Asynchrone Nachricht, Sender erwartet keine Antwort. NAchricht wird nicht konsumiert, d.h. auch andere Empfänger könne diese empfangen

Interface, API (A beiete an, B nutzt)

Anternatives Interface

Eine User Story ist eine textliche Anforderung an das System aus Anwender-Sicht.

Typischerweise werden User Stories gemäss folgender Vorlage strukturiert:

"Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>"

• User Stories beschreiben funktionale Anforderungen an ein System aus Anwender-Sicht. Jede Story muss für den Anwender einen klaren Nutzen erbringen und für den Anwender verständlich sein (keine technischen Lösungsbeschreibungen).

• User Stories müssen im Rahmen des Projektes (siehe dazu Einsatz in SoDa) so umformuliert und in mehrere Stories zerlegt werden, dass die im Rahmen eines Sprints umgesetzt werden können.

User-Stories benötigen:

- Akzeptanzkriterien (In einer Liste Bedingungen aufführen, die erfüllt sein müssen, damit die Story akzeptiert wird)

- Randbedingungen (wie muss es technisch umgesetzt werden, bsp welche DB, mit Product-owner absprechen) 

- Aufwandschätzung

- Priorität

Die Methoden GET, PUT und DELETE sollen beliebig oft aufgerufen werden können, ohne Seiteneffekte hervorzurufen!

• Implementation als idempotente Methoden.

Die Methode POST darf nicht mehrfach aufgerufen werden, da sie Seiteneffekte hat / haben kann (nicht idempotente Methode).

Info:
Rein lesende Services sind von Natur aus idempotent, da der Zustand der Daten nicht geändert wird. Jeder nicht idempotente schreibende Service kann aus fachlicher Sicht zu einem idempotenten Service gemacht werden.

Bsp:
Bei einem Service zum Verbuchen von Geldbeträgen ist der Aufruf einzahlen(100) nicht idempotent, da bei mehrmaligem Service-Aufruf der Betrag 100 mehrmals eingezahlt wird. Würde man hingegen neuerKontostand(600) aufrufen, so würde bei mehrmaligem Service-Aufruf der Kontostand gleich bleiben. Dieser Aufruf wäre idempotent.

Akzeptanzkriterien:
In einer Liste Bedingungen aufführen, die erfüllt sein müssen, damit die Story akzeptiert wird. Hier wird im Detail geklärt, wie eine User Story funktionieren soll. Häufig werden hier Fehlerbehandlungen, gesetzliche Anforderungen, nichtfunktionale Anforderungen etc. festgehalten. Sie sollten aber Lösungsneutral (nicht-technisch) sein!

Bsp:

• Wenn sich ein Student einer anderen Fakultät anmeldet, muss eine Fehlermeldung erscheinen.

• Wenn der Studierende bereits angemeldet ist, muss eine Fehlermeldung erscheinen.

• Wenn bereits alle Plätze in einer Vorlesung mit begrenzter Teilnehmerzahl vergeben sind, kann sich der Studierende nicht mehr anmelden.

• Der Studierende kann sich bei einer Vorlesung mit begrenzter Teilnehmerzahl anmelden, wenn noch nicht alle Plätze vergeben sind.

(technische) Randbedingungen:
Die hier genannten Bedingungen müssen für die Umsetzung der Story eingehalten werden, diese müssen mit dem PO abgesprochen und schriftlich festgehalten werden.

Bsp:
Im Rahmen einer Story müssen auch Daten gespeichert werden. Die entsprechende Datenbank ist aber noch nicht vorhanden und kann/soll im Rahmen dieser Story auch nicht umgesetzt werden. Als technische Randbedingung könnte nun festgehalten werden, dass die Daten über ein wohldefiniertes Interface und einem entsprechenden Mock «persistiert» werden.

Softwarearchitektur definiert sich durch die Kernelemente eines Systems, welches als Basis für alle weiteren Teile nur schwer und aufwendig verändert werden können.
Martin Fowler

Die Architektur repräsentiert die signifikanten Designentscheidungen die ein System festhalten, wobei die Signifikanz an den Kosten von Änderungen bemessen wird.
Grady Booch

Man unterscheidet übersichtshalber zwischen folgenden Aspekten der Software-Architektur:

- Grundlegende Struktur

- Kommunikation und Verarbeitung

- Eingesetzte Technologien

Arten von Applikationen:

• Einzelbenutzerapplikation
• Mehrbenutzerapplikation
• Internetanwendungen

• Präzisere Schätz- und Planbarkeit
• Unabhängige Entwicklung möglich
• Einfache Testbarkeit
• Unabhängiges Deployment
• Potential für Wiederverwendung höher

Komponente = Softwaretechnische Einheit. Dadurch kann ein System realisiert werden. Eine Komponente kann zur Realisation von mehreren Systemen verwendet werden.

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