Definizione dei confini e comunicare tra radici aggregate

Question

Potrei usare un po 'di aiuto per capire il mio modello di dominio un po' e assicurarmi di essere avvicinato correttamente al design.

Ho una radice aggregata chiamata dipartimento. L'oggetto del Dipartimento ha diversi tipi di valore infantile che aiutano a definire la nozione di business di un "dipartimento". Nei miei utenti dell'interfaccia utente possono elencare, creare, modificare ed eliminare oggetti reparto.

Ho un'altra radice aggregata chiamata progetto. Un progetto ha diversi tipi di valore figlio, ma ha anche una relazione con un dipartimento in quanto ogni progetto è "di proprietà" da un dipartimento. I progetti possono essere creati, modificati, cancellati, ecc. E facendo ciò non ha alcun impatto sul reparto mentre la rimozione di un dipartimento rimuove anche qualsiasi progetto che possiede.

La mia UI mostrerà un elenco di progetti in base ai dipartimenti che l'utente corrente è autorizzato ad accedere. Potrebbero essere in grado di accedere a più di un dipartimento. Quando viene visualizzato sia come elemento di elenco che in dettaglio, ho bisogno di mostrare il logo del reparto con il progetto.

Il mio primo pensiero è stato il progetto era una radice aggregata con una semplice proprietà reparto che potrebbe essere utilizzata per "cercare" il dipartimento. Ma ora sto iniziando a pensare che ho davvero solo una radice aggregata: dipartimento.

Cosa ne pensi?

Aggiornamento

Non so se è fondamentale per la discussione o cambia altro che il seguente pensiero mi è venuto in mente dopo aver letto la prima coppia di risposte.

Dipartimento sembra avere due contesti:

.
1. come entità autonoma che Supporta la modifica.
2. come figlio di un progetto in cui Il caso è contiene dati di sola lettura e Nessun comportamento.

   Questo mi fa pensare che dovrei avere due "oggetti" nel mio modello, una radice aggregata per il caso n. 1 e un tipo di valore per il caso n. 2. Sono sulla strada giusta?

Answer 1

Since the Project can't exist without a Department it's probably not an Aggregate Root. From your description it sounds like you only have one AR - the Department, which you use to manage the projects inside it.

If your behavior is mostly CRUD, i would not recommend building a full blown domain model for it since there are probably simpler approaches you can take.

UPDATE As you mention, you might have 2 bounded contexts here. One where the Department is an AR and the Projects are entities of this AR. In this context you would perform operations on your Departments. In a second BC your Project could be the AR and the Departments could be entities or VOs. This would allow you to work directly with projects.

I would also recommend going over this with your domain expert and see if these concepts fit well in your UL, or maybe search for some missing concept that can clarify your model. I would especially look for a concept that might link projects to departments.

Answer 2

I think it's perfectly defensible to have both Project and Department be aggregate roots, since they are both managed independently.

That is, every Project and every Department have some kind of unique identifier, and while you can add Projects to Departments, Projects themselves are probably complicated enough (with their own lifecycles, their own child objects etc.) to warrant aggregate root status.

You just have to keep a reference to the Department in each Project.

Answer 3

Few simple questions to be answered:

1) can the department domain object live by its own without the Project domain object. - If yes, then the department is an aggregate.

2) Is the Project domain object can live by its own - If yes, then the Project is also an aggregate

3) Is Project has relationship with one Department - Then it should be part of the Project aggregate exposed as property Department

4) Is Department has relation ship with one or more Project objects - The the Project aggregate should be part of the Department aggregate object.

So, Using Department aggregate object you might need to access the list of Project(s) object and once you have the Project object you might need to access the Department object. It is a circular reference which is obsoletely fine.

It is a typical example of Employee has a manager and manager has a list of employees