flowing retail
1.0.0
Diese Beispielanwendung demonstriert ein einfaches Auftragsabwicklungssystem, das in mehrere unabhängige Komponenten (wie Microservices ) zerlegt ist.
Das Repository enthält Code für mehrere Implementierungsalternativen, um einem breiten Publikum das Verständnis des Codes und den Vergleich von Alternativen zu ermöglichen. Die folgende Tabelle listet diese Alternativen auf.
Das Beispiel berücksichtigt Erkenntnisse aus Domain Driven Design (DDD) , Event Driven Architecture (EDA) und Microservices (µS) und soll Ihnen einen praktischen Zugang zu diesen Themen ermöglichen.
Hinweis: Der Code wurde zur Erläuterung geschrieben. Daher bevorzuge ich vereinfachten Code oder Copy & Paste gegenüber produktionsfertigem Code mit generischen Lösungen. Betrachten Sie nicht die Best Practice des Codierungsstils! Es ist so geschrieben, dass es sich um leicht erklärbaren Code handelt .
Weitere Informationen zu den Konzepten finden Sie im Buch „Practical Process Automation“ von O'Reilly.
Flowing Retail simuliert ein sehr einfaches Auftragsabwicklungssystem:
Die grundlegendste Wahl ist die Auswahl des Kommunikationsmechanismus :
Nach dem Kommunikationsmechanismus ist die nächste Wahl die Workflow-Engine :
und die Programmiersprache :
Flowing Retail simuliert ein sehr einfaches Auftragsabwicklungssystem. Die Geschäftslogik ist in die oben dargestellten Dienste unterteilt (dargestellt als Kontextkarte).
Einige Dienste sind von Natur aus langandauernd – zum Beispiel: Der Zahlungsdienst fordert Kunden auf, abgelaufene Kreditkarten zu aktualisieren. Eine Workflow-Engine wird verwendet, um diese lang andauernden Interaktionen beizubehalten und zu steuern.
Beachten Sie, dass die Zustandsmaschine ( oder in diesem Fall die Workflow-Engine ) eine Bibliothek ist, die innerhalb eines Dienstes verwendet wird. Wenn verschiedene Dienste eine Workflow-Engine benötigen, können sie jede gewünschte Engine ausführen. Auf diese Weise ist es eine autonome Entscheidung des Teams, ob und welches Framework verwendet werden soll:
