Conception pilotée par domaine: comment gérer les entités utilisateur dans un contexte délimité différent?

Question

J'ai une question concernant Domain Driven Design. Dans le contexte du compte utilisateur/profil lié de mon application, il y a une entité utilisateur avec des informations de compte (identifiant, nom d'utilisateur, mot de passe, email, sel, etc.) et des informations de profil (nom complet, avatar, anniversaire, sexe, etc.). J'ai également un autre contexte délimité pour les postes/demandes d'emploi, dans lequel chaque poste a un utilisateur employeur et chaque demande d'emploi a un utilisateur demandeur.

La question est de savoir si l'utilisateur employeur/demandeur dans un contexte lié à un emploi est la même entité utilisateur que j'utilise pour un contexte lié à un compte d'utilisateur. Ou devrais-je concevoir différentes entités de type Utilisateur pour l'Employeur et le Candidat?

Comme vous le voyez, seules les informations telles que id, fullname, email et avatar du contexte délimité par le compte sont pertinentes dans le contexte lié au job. Si l'employeur/demandeur est la même entité utilisateur du profil compte/utilisateur, il chargera beaucoup plus de données inutiles (pas besoin de connaître le mot de passe de l'utilisateur pour un employeur/demandeur). Mais si je leur crée des classes d'entités différentes, cela compliquera la persistance des données car les modifications apportées dans différentes classes d'entités peuvent modifier les mêmes données dans la même table de base de données.

Qu'en pensez-vous? Dois-je utiliser une entité utilisateur pour tous ou des entités utilisateur différentes pour différents contextes/agrégats liés? Si ce dernier est souhaitable, comment puis-je faire avec la persistance des données/entités?

Answer 1

C'est une vieille question et vous avez probablement résolu ce dilema d'une façon ou d'une autre, mais je vais essayer d'y répondre.

Vous avez écrit:

« Seules les informations comme id, fullname, e-mail et avatar du contexte limité compte est pertinent dans le travail contexte délimité »

Sont-ils vraiment pertinents pour Job BC? Avec les entités (et même plus: avec les agrégats), vous modélisez les processus, pas les données. Dans quel processus ou cas d'utilisation de Job BC avez-vous besoin de fullname? Existe-t-il dans le domaine une exigence selon laquelle les personnes ayant un prénom ou un nom de famille spécifique ne devraient pas être employées? Je suppose que non. En disant cela, vous aviez probablement à l'esprit que vous deviez afficher des écrans où le nom complet d'une personne avait été affiché. Mais les écrans ne sont pas des processus, ils sont juste rapports. Vous ne devez pas conduire votre modèle par des rapports/écrans/UI, mais par des processus qui existent dans un domaine spécifique.

Ok, mais comment faire? Évidemment, vous devez encore générer des rapports/écrans. N'est-ce pas? La réponse est: vous avez besoin de CQRS (https://martinfowler.com/bliki/CQRS.html). La pile de commandes est juste votre modèle de processus atteint par les agrégats etc. Ainsi, vos blocs de construction seront conservés par certains ORM. Et le modèle de données pour eux sera conduit par la façon dont ils (les blocs de construction) ressemblent. Utilisez ici un ORM qui peut facilement persister, même avec Aggregate complexe, par exemple Hibernate.

Ensuite, vous devez construire la pile de requêtes. Je vois deux façons de l'atteindre et cela dépend si vous avez les deux BC dans le même schéma DB ou non. Lorsque les deux BC sont sur le même schéma, utilisez simplement des vues de base de données qui construiront des données pour vos rapports/écrans. Utilisez certains très rapides et flexibles pour les requêtes complexes ORM ici comme MyBatis ou Spring JDBC (ou même JDBC simple si vous aimez lutter contre la colère JDBC;)). N'utilisez pas Hibernate ici si vous n'y êtes pas obligé, car vous constaterez qu'il est bon d'être aussi proche de SQL que possible dans cette pile.Les abstractions de requête de données vous obligeront à vous battre avec le framework/ORM utilisé pour réaliser des jointures complexes de modèle de données qui sont pilotées par des agrégats et leurs processus, et non des écrans. Une autre raison est que dans les applications métier ordinaires, il y a plusieurs lectures d'ordres de grandeur que les écritures sur DB, en CQRS, il y a plus d'utilisations de pile de requêtes que d'utilisations de pile de commandes. Lorsque les BC sont sur des schémas différents, vous devez créer la base de données de rapports (https://martinfowler.com/bliki/ReportingDatabase.html) qui va "fusionner" les deux schémas. Ensuite, vous pouvez faire des vues sur le schéma fusionné et le problème se simplifie au-dessus d'un. Veuillez noter que Reporting Database vous offre une autre possibilité de mise à l'échelle: cette base de données est en lecture seule, elle peut donc être facilement répliquée sur plusieurs serveurs, vos services de pile Query peuvent être multipliés et cachés derrière Load Balancer.

Ok, mais qu'en est-il de la propriété d'adresse e-mail? Vous avez probablement un cas d'utilisation dans votre domaine que l'employeur ou le demandeur doit être informé de certaines actions/processus effectués sur le domaine. Je pense que le service de domaine (ou gestionnaire d'événements de domaine) qui gère ce cas d'utilisation devrait demander au service de messagerie d'autres utilisateurs de cet utilisateur particulier (ou événement de domaine de diffusion qui sera géré quelque part). Ou encore mieux - il devrait déléguer ce travail à un service de notification dans un autre pays bénéficiaire. Et ce service de notification demandera le service de Account BC pour l'adresse e-mail. À mon avis, le contexte borné (avec le langage omniprésent) est l'idée la plus importante de DDD. C'est un outil vraiment puissant pour éviter la grosse boule de boue pendant la modélisation. Et il n'est vraiment pas facile de déterminer le contexte borné dans les domaines réels :)