Est-ce que je brise mes limites agrégées dans ce modèle?

Ceci est une relation typique à plusieurs à plusieurs. Et les tables d'organisation_USEURS sont la table de pont. Infactez NHibernate et tous les autres outils Orm ont une fonctionnalité intégrée pour prendre en charge la table du pont.

Cette chose doit être résolue au niveau de la modélisation des données plutôt qu'au niveau de l'application. Vous devez analyser votre modèle de données et il est recommandé d'éviter des relations de nombreuses personnes (en ce sens que si ce n'est pas la nécessité du modèle de domaine, vous devriez essayer d'éviter une relation de nombreuses personnes).

première chose d'abord, vous devez être sûr que beaucoup à plusieurs relations dans le modèle de données est nécessaire pour la cartographie des entités de domaine. Une fois que vous avez fait cela, le modèle représenté dans votre diagramme est correct pour la cartographie de ces relations au niveau de l'application

Les premières choses à considérer dans DDD sont:

• oublie votre schéma de base de données (il y a Pas de base de données!)
• Quelles actions effectuerez-vous sur Thoses d'une perspective de domaine?

Ma compréhension est la suivante:

Un utilisateur peut appartenir à 0-à-de nombreuses organisations. ET Une organisation se compose de 0 à plusieurs utilisateurs.

sont-ils tous deux de ces deux corrects? Si oui, cela sonne comme un grand-à-plusieurs pour moi.

Dans un nombre à plusieurs, vous avez à peu près besoin d'un objet ressemblant à une relation d'une sorte pour combler cette lacune. Le problème est qu'il n'y a pas d'utilisateur_organisation dans le domaine.

Cela me fait penser que vous ne devriez pas avoir User_Organization dans une partie de votre domaine, en soi. Cela ressemble à un détail de mise en œuvre.

D'autre part, peut-être que cela a du sens dans votre domaine d'avoir une liste qui détient les utilisateurs d'une organisation et stocke leur rôle et ses autres informations spécifiques à cette relation.

Je pense que votre modèle va bien. Je pense généralement aux racines d'agrégats de domaine, lorsque je pense à eux du tout, en termes de ce qui est exposé publiquement, pas de mise en œuvre interne. Avec des relations, je pense à quelle entité "porte le pantalon" dans la relation. C'est-à-dire que c'est plus naturel d'ajouter un utilisateur à une organisation ou d'ajouter une organisation à un utilisateur? Dans ce cas, les deux peuvent avoir un sens, un utilisateur rejoint une organisation; Une organisation accepte un utilisateur pour l'adhésion.

Si votre domaine voit la relation du point de vue de l'utilisateur, vous pouvez mettre les méthodes à maintenir (ajouter, supprimer, etc.) la relation sur l'utilisateur et exposer une collection en lecture seule sur l'organisation.

En réponse à votre deuxième design (cela aurait été mieux si vous aviez édité la question originale): je n'aime pas le tout. Votre conception originale va bien. Je n'ignorerais pas nécessairement la base de données lors de la conception de vos classes, une bonne conception doit modéliser avec précision le domaine et être simple à mettre en œuvre dans une base de données relationnelle. Parfois, vous devez faire des compromis dans les deux sens pour frapper la touche sucrée. Il n'y a pas de trimestre de prison pour briser les frontières globales. : -)

Merci à tous pour vos réponses. Ils ont été très utiles.

Pendant que je pensais à mon modèle un peu plus, j'ai esquissé quelque chose de nouveau que je pense serait mieux.

Ma pensée était ceci:

1. Lorsqu'un utilisateur se connecte au site, le système trouve son compte, puis renvoie une liste d'organisations à part et obtient cette information à partir de l'objet user_organizations.

2. Lorsqu'un utilisateur clique sur l'une des organisations qu'elles sont en dehors de celle-ci les dirige vers le panneau de commande de l'organisation.

3. L'organisation sélectionnée lève ensuite le rôle de cet utilisateur dans son organisation org_user_details de savoir quel accès à l'utilisateur doit avoir à ce panneau de contrôle des organisations.

   Est-ce que ça a du sens? :)

   Je me sens comme ça serait bon dans un modèle, mais j'ai des doutes sur la mise en œuvre de la DB. Je sais que je ne devrais même pas m'inquiéter, mais je ne peux pas encore casser ma mauvaise habitude! Vous pouvez voir qu'il existe des données en double dans l'objet user_Organizations et l'objet org_user_details. Je ne suis pas un dB Pro Mais est-ce qu'un mauvais design de DB? Devrais-je combiner plutôt les données de user_organizations et org_user_details dans une table comme celle de mon premier message et simplement dire à NHibernate que l'utilisateur l'examine comme une relation et une organisation nombreuses à plusieurs. ? Cela ressemble à je trompe le système. Désolé si j'ai semblé vraiment confus à ce sujet.

   Quelles sont vos pensées à ce sujet? Est-ce que je pensais ça? : P

J'ai utilisé une approche similaire à votre premier modèle à plusieurs reprises. Le seul attrape avec cette approche est que vous devez créer une classe oganizationUser forte> dans votre domaine pour gérer les champs em> et marqués de votre domaine de votre domaine. Cela vous laisserait avec quelque chose comme celui-ci dans votre code.

var user = userRepository.Load(1);
var list = user.OrganizationUsers; // All the organizations the user is a part of including their role and flagged values.

var organization = list[0].Organization;