flowing retail

Commerce de détail fluide

Cet exemple d'application présente un système d'exécution des commandes simple, décomposé en plusieurs composants indépendants (comme les microservices ).

Le référentiel contient du code pour plusieurs alternatives d'implémentation afin de permettre à un large public de comprendre le code et de comparer les alternatives. Le tableau ci-dessous répertorie ces alternatives.

L'exemple respecte les apprentissages de Domain Driven Design (DDD) , Event Driven Architecture (EDA) et Microservices (µS) et est conçu pour vous donner un accès pratique à ces sujets.

Remarque : Le code a été écrit afin d'être expliqué. Par conséquent, j'ai privilégié le code simplifié ou le copier-coller plutôt que le code prêt pour la production avec des solutions génériques. Ne considérez pas les meilleures pratiques en matière de style de codage ! Il est spécialement écrit pour être un code facilement explicable .

Vous pouvez trouver plus d'informations sur les concepts dans le livre Practical Process Automation avec O'Reilly.

Flowing Retail simule un système de traitement des commandes très simple :

Alternatives d’architecture et de mise en œuvre

Le choix le plus fondamental est de sélectionner le mécanisme de communication :

• Apache Kafka comme bus d'événements (pourrait être facilement modifié en messagerie, par exemple RabbitMQ) :
• Communication REST entre les services.
  • Cet exemple montre également comment créer des modèles de résilience avec état, tels que des tentatives avec état, en exploitant un moteur de workflow.
• Courtier Zeebe effectuant la répartition du travail.

Après le mécanisme de communication, le choix suivant est le moteur de workflow :

• Camunda 8 (alias Zeebe)

et le langage de programmation :

• Java

Scénario

La vente au détail fluide simule un système d’exécution des commandes très simple. La logique métier est divisée en services indiqués ci-dessus (affichés sous forme de carte contextuelle).

Services et orchestration de longue durée

Certains services durent par nature - par exemple : le service de paiement demande aux clients de mettre à jour les cartes de crédit expirées. Un moteur de workflow est utilisé pour conserver et contrôler ces interactions de longue durée.

Les flux de travail vivent dans les limites des services

Notez que la machine à états ( ou le moteur de workflow dans ce cas ) est une bibliothèque utilisée au sein d'un seul service. Si différents services ont besoin d'un moteur de workflow, ils peuvent exécuter le moteur de leur choix. De cette façon, c'est une décision d'équipe autonome si elle souhaite utiliser un framework, et lequel :

Liens et lectures de fond

• Livre pratique sur l'automatisation des processus
• Article de blog d'introduction : https://blog.bernd-ruecker.com/flowing-retail-demonstrating-aspects-of-microservices-events-and-their-flow-with-concrete-source-7f3abdd40e53
• InfoQ-Writeup « Événements, flux et services de longue durée : une approche moderne de l'automatisation des flux de travail » : https://www.infoq.com/articles/events-workflow-automation