Dans mon projet, j'ai un flux de travail qui fonctionne sur plusieurs entités pour accomplir une transaction commerciale. Quel est le meilleur endroit pour représenter la logique de flux de travail? Actuellement, je viens de créer un "XXXManager" qui est responsable de la collaboration avec des objets d'entité pour conclure une transaction commerciale. Y a-t-il d'autres options?
5 Réponses :
DDD pourrait ne pas être exactement sur ce genre de chose, alors je suggérerais de jeter un coup d'oeil au modèle architectural de la couche de service. Les modèles de livre de Martin Fowler de l'architecture d'entreprise sont un bon livre qui l'expliquera. Vous pouvez également trouver la description du modèle sur le site Web de Fowler.
Créer des systèmes de flux de travail peut être une perspective intimidante. Avez-vous envisagé d'utiliser Moteurs de flux de travail ?
Si je vous comprends correctement, vous devrez créer un gestionnaire qui garde la trace des différentes transactions dans le flux de travail, lié à l'utilisateur. Il y a probablement d'autres moyens de le faire - mais j'ai toujours utilisé des moteurs.
Il existe généralement un objet de domaine qui devrait réellement gérer le contrôle qui se trompe pour une "entité".
Y a-t-il une instance de quelque chose qui est créé à la suite de ce flux de travail? Si tel est le cas, la logique de flux de travail appartient probablement là. Considérer "ordre" dans le modèle ci-dessous.
Texte alt http://img685.imagesShack.us/img685/4383/order .png
Oder est à la fois un nom et un verbe. L'ordre est l'objet créé à la suite d'une "commande". Comme toute bonne classe, il a à la fois des données et un comportement (et je ne veux pas dire getters et setters). Le comportement est le processus dynamique qui va avec les données, c'est-à-dire le flux de travail de commande. "Commander" est le contrôleur.
C'est pourquoi OO a été inventé.
On pourrait dire que la modélisation de domaine oo est sur la nomination des verbes.
Je dirais que vous faites la bonne chose d'avoir quelque chose de collaborer avec plusieurs entités pour faire quelque chose. L'important est que chaque entité (et bien chaque service) devrait avoir un Responsabilité unique . < / p>
Le flux de travail global dont vous parlez est quelque chose que vous pouvez considérer comme une partie de votre couche d'application.
Selon Paul Gielens (paraphrasé) La responsabilité de la couche d'application est de digérer les demandes (messages / commandes) de cours (messages / commandes) pour atteindre un certain objectif global. Cela le fait en envoyant un message aux services de domaine pour l'accomplissement. Il décide également (éventuellement) d'envoyer des notifications au service d'infrastructure.
Mais alors qu'est-ce qu'un "service" ?! C'est un terme surchargé, mais celui qui est décrit bien (encore une fois, Par Paul Gielens )
Vous voudrez peut-être aussi lire sur Architecture d'oignon pour Plus d'idées ...
TXN pour la référence d'architecture d'oignon, article intéressant!
Aux grandes réponses, j'aimerais ajouter "" Événements de domaine " (lien vient d'une implémentation possible) qui est quelque chose d'Evans lui-même est venu de mettre davantage de se concentrer sur (" accentuation accrue sur les événements ").
