granularité du service

Question

Quelle est la meilleure façon de gérer les services spécifiques à un domaine? Par exemple: Dans un domaine financier, Devrais-je avoir un service global "AccountCreation" ou "CheckingAccountCreation", "CreditcardAccountreation" etc.

Je suis en difficulté de les garder au niveau mondial ou de les garder au niveau du produit. Quelle est la meilleure approche?

Answer 1

Vous devriez d'abord vous concentrer sur les données: quelles sont les données et quelles données doivent rester cohérentes. Ensuite, concentrez-vous sur les comportements autour de ces données.

Dans un domaine financier, devrais-je avoir un service global "AccountCreation" ou "CheckingAccountCreation", "CreditcardAccountreation", etc.

Dans cet exemple, je dirais que vous avez un "compte" service, parce que vous avez clairement quelques comptes - et vous devez probablement veiller à ce que, par exemple, vous ne dupliquiez pas les numéros de compte, n'appliquiez pas les règles anti-fraude, ne gériez pas le workflow de création, etc

Vos exemples identifient certains comportements : créer un compte chèque, créer un compte de carte de crédit. Ceux-ci seraient de manière appropriée des commandes que vous envoyez au service, car elles entraînent une mutation des données que le service possède. Toutefois, si vous ajoutez un service "client" distinct du service de comptes, il n'est pas nécessaire qu'il soit cohérent avec le service de compte, simplement pour avoir une référence des comptes aux clients par ID. Vous n'avez généralement pas de comportement partagé qui touche les deux parties: la mise à jour des données relatives à un client ne doit pas toucher les détails de son compte (directement) et la mise à jour d'un compte ne modifie pas les détails d'un client. Vous pouvez avoir des règles métier dans un service qui en changent une autre, comme le service de compte écoutant "un client devenu étudiant" annoncé par le service client, puis effectuant un traitement interne.