UnitOfWork

[eglauko]

Hoje existe o IUnitOfWorkContext que gerencia a finalização da unidade de trabalho e transações. Este componente trabalha junto com os repositórios, os quais armazenam em memória as entidades da operação.

É necessário unificar as operações de unidade de trabalho e repositório, incluindo também a pesquisa com ISearchable.

Para isto, é necessário criar um IUnitOfWork que herde as funcionalidades de IUnitOfWorkContext e disponibilize IRepository e ISearch para as entidades relacionadas/configuradas para a unidade de trabalho.

Isto deverá ser feito separadamente do projeto atual, para que se possa trabalhar independentemente.

[eglauko]

É considerável uma renomeação das coisas.

A classe atualmente chamada IUnitOfWorkContext poderia ser chamada apenas de IUnitOfWork e mantida no projeto atual.

Um novo projeto chamado RoyalCode.UnitOfWork.Context, ou algo similar, poderia ser criado. Este novo projeto conteria um IUnitOfWorkContext (novo) que herdaria o IUnitOfWork (renomeado) adicionando métodos para obter os repositórios e consultas.

[eglauko]

Lendo sobre Repository e DAO cheguei a ponto de concordar com a conclusão acima, mas com uma pequena mudança de nomes. Artigo: Domain Driven Design in Java: Repositories and DAOs part 3

Na descrição é comentado que os repositórios e o DAO são similares em muitos detalhes, mas a abordagem é um pouco diferente. Enquanto os DAO são focados na base de dados, criando um por tabela ou entidade, os repositórios são focados nos modelos de domínio, criando um por aggregate.

Neste sentido, temos o padrão IUnitOfWork com sua especificação/definição e outra coisa que irá representar uma unidade de um bounded context, portanto poderia ser um IUnitOfWorkContext, por exemplo.

Este IUnitOfWorkContext estaria focado no bounded context, no domínio, enquanto seu similar a nível de base de dados seria o DbContext, com foco em mapeamentos e entidades relacionada a tabelas.

Assim o IUnitOfWorkContext seria um componente/padrão que trataria do IUnitOfWork, do acesso a repositórios e outros padrões de dados mais relacionados ao domínio, como o padrão Search-Filter-Specifier.

[eglauko]

A questão dos nomes:

Poderia ser chamado apenas de IContext?

O termo é muito genérico mas é considerável. Outros termos como IDbContext faria referência ao banco de dados e tiraria o foco do bounded context. A mesma coisa com IEntityManager. Já IDomainContext faria muita referência ao domínio, sendo que ele estaria mais ligado a camada de aplicação. Com este termo pareceria que o domínio teria acesso a unidade de trabalho e poderia controlar transações. Por este motivo é melhor evitar o uso.

No post do link do comentário acima tem um comentário interessante:

i attended one of Eric Evans's courses on DDD and asked him the question: What's the difference between a repo and a dao? He answered (word-by-word quotation): "Repos can be implemented in many ways, one way is a DAO"

Com essa resposta, o IContext poderia ser implementado como uma unidade de trabalho ou não. Mas devemos considerar que nestas implementações será implementado desta forma.

A questão é se devemos usar IContext ou IUnitOfWorkContext ?

[eglauko]

Resolução: Foi deixado IUnitOfWorkContext como já era.

Foi criado um IWorkContext que era a unidade de trabalho (citada acima) e disponibiliza os Repositórios e as Pesquisas.