Definindo limites e comunicando entre raízes agregadas

Question

Eu poderia usar alguma ajuda para entender meu modelo de domínio um pouco e certificando-se de que estou se aproximando corretamente do design.

Eu tenho uma raiz agregada chamada departamento. O objeto de departamento tem vários tipos de valor infantil que ajudam a definir a noção de negócios de um "departamento". No meu usuário UI pode listar, criar, editar e excluir objetos do departamento.

Eu tenho outra raiz agregada chamada projeto. Um projeto tem vários tipos de valor infantil, mas também tem uma relação com um departamento em que cada projeto é "de propriedade" por um departamento. Projetos podem ser criados, editados, excluídos, etc. e, portanto, não tem impacto no departamento, enquanto a remoção de um departamento também remove qualquer projeto que possui.

Minha UI exibirá uma lista de projetos com base nos departamentos que o usuário atual está autorizado a acessar. Eles podem ser capazes de acessar mais de um departamento. Quando exibido como um item de lista, bem como em detalhes, eu preciso mostrar o logotipo do departamento com o projeto.

Meu primeiro pensamento foi o projeto foi uma raiz agregada com uma propriedade de departamento simples que poderia ser usada para 'Pesquisar' o departamento. Mas agora estou começando a pensar que eu realmente só tenho uma raiz agregada: departamento.

O que você acha?

update

Eu não sei se é fundamental para a discussão ou altera qualquer coisa, mas o seguinte pensamento me ocorreu depois de ler as primeiras respostas.

Departamento parece ter dois contextos:

.
1. como uma entidade independente que Suporta modificação.
2. como filho de um projeto em que O caso é contém dados somente leitura e sem comportamento.

   Isso me faz pensar que eu deveria ter dois 'objetos' no meu modelo, uma raiz agregada para o caso 1 e um tipo de valor para o caso # 2. Estou no caminho certo?

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