Racines agrégées. Jusqu'où va le trou du lapin

Question

J'essaie d'utiliser le modèle Repository pour mon projet actuel et je suis actuellement en train d'essayer de modéliser le domaine et de trouver les racines agrégées. J'ai lu la règle 'Supprimer en cascade' qui stipule que si cela n'a pas de sens de supprimer un membre lorsque la racine est supprimée, cela ne devrait pas faire partie de la racine.

Je vais utiliser un incident de police comme eample: -

Incident (racine d'agrégat) - Cela pourrait contenir les enquêteurs, les notes prises par chaque agent. Il pourrait également contenir des suspects avec une liste de dates qui ont été interviewés. Des images de vidéosurveillance ont-elles été obtenues pour l'incident? Un journal de chaque fois que la CCTV a été vue et par qui? Des copies ont été faites de la vidéosurveillance pour la preuve/tribunal, etc.

Il semble que l'IncidentAggregate puisse devenir énorme car il semble que tout se bloque sur cet incident.

Ma question est double: combien la racine agrégée doit-elle gérer et les racines dans les racines sont-elles une bonne idée?

Ceci peut ne pas être un exemple particulièrement bon puisque vous ne supprimerez probablement jamais quelque chose comme un incident de police mais j'espère qu'il décrit mieux ma question.

Answer 1

Un agrégat contient généralement les références à d'autres racines d'agrégats. Ces références doivent être supprimées lorsque l'agrégat contenant est supprimé, mais les agrégats qu'elles pointent resteront.

Pour utiliser votre analogie. Un rapport que nous supposerons fait partie d'un seul agrégat d'incidents et serait supprimé avec l'agrégat. Aucun autre agrégat n'accèderait directement à ces rapports.

Cependant, l'agrégat d'incidents référencerait agrégats représentant les officiers, les suspects et les entrées des journaux de visualisation CCTV.

Answer 2

Un agrégat est un groupe d'objets ayant le même cycle de vie.

Si vous supprimiez un incident, voudriez-vous également supprimer l'enquêteur? Non. Si vous le faisiez, vous n'auriez bientôt plus de policiers. L'enquêteur n'est pas dans l'agrégat d'incidents. Parmi les autres choses que vous listez, les suspects, les interviews, la vidéosurveillance, etc. La réponse est - cela dépend.

Cela dépend de votre domaine de problème. Que fait votre système? quelle est sa portée? quel problème résout-il? Si le seul travail consiste à suivre une série d'incidents et à supposer que les suspects, les interviews et la vidéosurveillance sont uniquement dans le système à la suite d'un seul incident, alors oui, les regrouper en un seul agrégat pourrait être approprié. Si l'incident est supprimé, les suspects, les interviews et CCTV peuvent partir. Par exemple, si vous suivez également des archives de vidéos CCTV collectées à partir d'un réseau de caméras du centre-ville. Peut-être que vous essayez de surveiller leur efficacité et leur fiabilité. Si c'est le cas, vous devez traiter différemment les vidéos CCTV. Ce serait dans un agrégat différent avec son propre cycle de vie. Si vous supprimez un incident, vous souhaitez conserver vos séquences de vidéosurveillance pour d'autres incidents et mesures de performance.Ce qui est dans et hors d'un agrégat dépend de votre domaine de problème. Ou plus précisément, cela dépend de la façon dont vous avez modélisé la solution du problème.

Pensez cycle de vie.

Answer 3

"Les racines dans les racines sont-elles une bonne idée?"

Réponse courte à mon avis est non. Comme Kurt dit, vous devriez garder références à d'autres agrégats. Pour être clair, par références, je veux dire identifier des objets. Alors peut-être votre total d'incident aurait une propriété telle que

public IEnumerable<Guid> InvestigatingOfficerIds 
{ 
    get { return _investigatingOfficerIds.AsReadOnly(); } 
} 

Ou

public IEnumerable<OfficerReference> InvestigatingOfficerIds 
{ 
    get { return _investigatingOfficerIds.AsReadOnly(); } 
} 

Par lequel OfficeReference est une classe qui représente la valeur d'une identité des officiers (sous le capot serait probablement un Guid). Si votre logique de domaine devait effectuer des actions en utilisant à la fois l'agent d'incident et les enquêteurs, cette logique serait abstraite d'un service de domaine et utiliser IOfficerRepository pour récupérer les agrégats d'agents à l'aide des ID fournis sur l'agrégat incident.