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.