During the last year or so, Domainlanguage and Citerus have been working on an example application that demonstrates how some typical DDD concepts can be realised when it comes to code. The applications is now ready to be shown in public.
[quote=“dddsample”]Lab mouse for controlled experiments
There’s a lot of interest in new tools or frameworks for DDD.
Reimplementing the sample app using a new platform will give a side-by-side comparison with the “conventional” implementation, which can demonstrate the value of the new platform and provide validation or other feedback to the developers of the platform.[/quote]
Seria legal se de fato acontecer debates e comparações lado a lado entre essa arquitetura ‘convencional’ e outras que já tenhamos desenvolvido ou que possamos desenvolver. Com certeza este é um exemplo que contribui muito para o entendimento de DDD.
Thiago, achei o exemplo bem interessante, mas surgiu uma duvida.
Se o Entity Cargo retorna uma referencia para um Location que tambem eh um Entity, o exemplo nao esta violando o proprio padrao?
O livro diz “Nothing outside the AGGREGATE boundary can hold a reference to anything inside, except to the root ENTITY.” e nesse caso eu tenho uma referencia fora da “fronteira”.
[quote=raulmferreira]Thiago, achei o exemplo bem interessante, mas surgiu uma duvida.
Se o Entity Cargo retorna uma referencia para um Location que tambem eh um Entity, o exemplo nao esta violando o proprio padrao?
O livro diz “Nothing outside the AGGREGATE boundary can hold a reference to anything inside, except to the root ENTITY.” e nesse caso eu tenho uma referencia fora da “fronteira”.
Talvez eu nao entendi bem o padrao, nao sei.
Se alguem puder me ajudar agradeco.
Valeu![/quote]
Tanto Cargo quanto Location sao ROOT, nao entendi qual a duvida.
[quote]Definition:
A cluster of associated objects that are treated as a unit for the purpose of data changes. External references are restricted to one member of the Aggregate, designated as the root. A set of consistency rules applies within the Aggregate’s boundaries.[/quote]
Se num to enganado vc ta se referindo ao exemplo do sistema de rotas que possui casos de uso que envolvem os agregados Cargo e Location. De acordo com a definicao acima nada impede Cargo possuir uma referencia externa ao Location. Mas sua duvida é pertinente porque o Location é passado pelo Cargo pra varios membros internos do seu agregado.
Acontece que agregados devem ser considerados do ponto de vista da atualizacao dos dados. Neste caso Location é um objeto sem muitas responsabilidades. É usado no exemplo pra criar um specification e outras coisas mas sempre apenas como “coadjuvante” (se bem que as vezes o objeto mais importante para uma regra de negocio, é aquele que retorna uma informacao importante ao inves de alterar o estado do sistema.).
Exemplo, se Location causasse alguma alteracao nos membros internos teria que ser atraves do Cargo (ja que ele é o Root). Assim como Cargo poderia receber nova Location caso necessario alterar o itinerario.
Minha ideia inicial sobre o padrao era que ele fosse implementado como uma especie de “facade”, com outro proposito claro e trabalhando com objetos atributos.
Por exemplo, se o objeto Location fosse persistido pelo Cargo entao nao poderia ser retornada uma referencia?
[quote=raulmferreira]Humm, acredito que entendi entao.
Minha ideia inicial sobre o padrao era que ele fosse implementado como uma especie de “facade”, com outro proposito claro e trabalhando com objetos atributos.
Por exemplo, se o objeto Location fosse persistido pelo Cargo entao nao poderia ser retornada uma referencia?
[/quote]
Agregados pertencem ao mesmo dominio, nao sao 2 partes separadas comunicando atraves de uma API. Logo, nao tem nada de facade.
Pense que o importante para um agregado nao é o que se retorna, mas que as operacoes que venham a alterar dadaos nos membros seja feito pelo root (Cargo).
Persistir Location vc estaria alterando o agregado Location, quem persiste neste caso (Cargo) nao importa, mas geralmente é feito por um service.
Outro detalhe que, o agregado so existe a partir do momento que entidade root ja existe no repositorio, neste caso a fronteira do agregado delimita o escopo das atualizacoes.
