Im Moment ist es so, dass die gesamte Anwendung in einer Solution gehalten wird. Es gibt für jeden Bounded Context einen Unterordner. Auf oberster Ebene gibt es das Projekt projekt.api, welches die gestartete / gehostete Anwendung darstellt. Intern sind die Kontexte getrennt, werden aber durch das api Projekt wieder zusammengeführt.

Projekt Struktur

vs-1

Durch diese Struktur ergeben sich folgende Nachteile:

  • relativ lange Build Laufzeit
  • Deployment nur am Stück möglich
  • „Keine richtige Trennung“ der Bounded Contexte

Es gibt im Wesentlichen 3 Komponenten pro Bounded Context, die ich aktuell als eigenständige Micrososervices sehe:

Command API

heißt im Moment noch Command Service. Dient dem Client als Endpunkt für Schreib-Operationen. Der Client schickt die Commands als Requests per Post an den Server. Folgendes passiert hier:

  1. Die Authentifizierung (Token) und ggf. die Authorisierung (Berechtigung) prüfen
  2. Den Request mit dem übergebenen Model syntaktisch validieren
  3. Ein Command erzeugen und in den Message-Bus schicken
  4. Command erfolgreich angenommen an den Client senden

Weiterhin passiert dann innerhalb der Domain Logik folgendes:

  1. Das Command wird von einer Saga abgefangen
  2. Das Aggregate aus dem Event-Store laden
  3. Die Domain Logik ausführen
  4. Die neu erzeugten Events im Event-Store speichern
  5. Die neuen Events durch den Message-Bus schicken

Man hat hier grundsätzlich auch die Möglichkeit, die Domain Logik in einen separaten Microservice auszulagern.

Query API

heißt im Moment noch QueryService. Dient dem Client als Endpunkt für Lese Operationen. Der Client fragt Daten per GET am Server an. Hier passiert folgendes:

  1. Die Authentifizierung (Token) prüfen
  2. Die Authorisierung (Berechtigung) innerhalb der Anwendung prüfen
  3. Die Read-Model(s) aus dem Cache oder dem Read-Model-Store laden
  4. Rückgabe der Read-Model-Daten an den Client

Projection API

heißt im Moment noch ProjectionService. Ist die Verbindung zwischen Command- und Queryseite. Das Read-Model wird hier aufgebaut. Das bedeuted folgendes:

  1. Registrierung einer Subscription pro Read-Model / Aggregat / Stream im Event-Store
  2. Aus den Events das Read-Model in der Datenbank aufbauen

Ziel

Im Moment sieht die Struktur so aus:

ist-struktur-01

So soll sie zukünftig aussehen:

soll-struktur-01

Fazit

Eine geeignete Aufteilung der großen Solution in mehrere Kleine muss her. Sinnvoll ist eine Trennung nach Bounded Context. Damit erhält dann auch jeder Kontext sein eigenes Git-Repository und eine eigene Build Pipeline. Dadurch werden die Visual Studio Solutions schlanker gehalten und die Build Laufzeit verringert.

Advertisements

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s