Domain Driven Design

[Cassio Pinheiro Almeron]

Boa Noite

Venho estudando DDD, lendo o livro do Evans, mas ainda sem nenhuma prática, por algumas dúvidas me surgiram.

Uma questão que me surgiu foi, lendo um dos capítulos iniciais do livro, onde havia um exemplo de emissão de pedidos, abordando o problema da concorrência.

No exemplo citava três usuários adicionando itens ao mesmo pedido, que da forma tradicional, ocorreriam problemas de atualização.

A solução de Evans conceitualmente é muito simples. basta apenas usar a mesma instância da classe Pedido para os três clientes, no lado servidor da aplicação.

Muito bom, jóia.....

Mas como funcionaria isso na prática? Cache nos Repositórios? Ou Várias instâncias de um mesmo objeto conceitual? (o que voltaria ao problema original)

Alguém saberia como seria o DDD aplicando esse conceito.

Grato

Cássio Almeron

[Cristian Mathias]

E ae Cássio, acho que você pode utilizar o padrão unity of work para isso.

Da uma olhada ai e diz o que você acha!

http://martinfowler.com/eaaCatalog/unitOfWork.html

Aqui um exemplo simples:

http://www.macoratti.net/12/06/asp_mvc9.htm

Abs

--
--
Acesse nosso blog http://devrs.net/
Siga-nos no twitter! http://twitter.com/DevRsNet
--
Antes de criar um novo post, para maior organização do grupo, procure seguir as regras de TAGS: http://devrs.net/regras-da-lista
Para postar para o grupo, envie email para de...@googlegroups.com
Para sair do grupo, envie email para devrs+un...@googlegroups.com

[Cassio Pinheiro Almeron]

Olá Cristian

Pelo que eu entendi olhando os exemplos com esse padrão UnitOfWork, realmente entrega a mesma instância do objeto, cachado pelo ORM, bacana.

Isso mesmo?

Ai começam a surgir outras questões que tenho dúvidas, DDD + ORM.

Até onde eu sei, o principio do modelo rico, é que um objeto nunca pode entrar em estado inválido.

Ou seja, por exemplo propriedades que são obrigatórias já devem ser passadas no construtor, caso um valor invalido entre no construtor, o objeto nem nasce.

No caso do NHibernate, é necessário que eu preencha todas as propriedades com virtual, e também é necessário que exista um construtor sem parâmetros.

Até onde eu sei, qualquer alteração no meu modelo de domínio para que possa ser usado por uma tecnologia é quebra de conceito.

O que tenho feito é ter em minha camada de repositório classes anêmicas para representar as entidades mapeadas para o banco, e ao retornar para as camadas superiores, é realizado uma Adapter para uma classe de Domínio.

Dessa forma o cache do ORM passa a ser inútil para o UnitOfWork.

Não sei se o que eu to fazendo é uma grande bobagem, mas foi a forma que encontrei até então para manter o conceito do modelo rico.

Segue em anexo um livro sobre o assunto, e com exemplos em C#

Grato

Cássio Almeron

[Cassio Pinheiro Almeron]

Olá

Lendo aquele livro que anexei no último Post encontrei uma resposta para está questão.

Onde diz que manter e compartilhar instâncias conceitualmente é o correto, porém na prática é problemático:

Ná página 164

Isolating or Sharing Instances

At the application server, should we have shared Domain Model instantiaton, per user or per

session? Well, I like the idea of a shared Domain Model instantiation in theory, but in practice I

prefer to stay away from it most often. It gets much more complex than what you would first

expect, so I go for a Domain Model instantiation per user instead or actually usually per session.

It's much simpler.

One of the main problems with a shared set of instantiated domain objects occurs if it has to

execute in a distributed fashion, perhaps on two application servers in a "shared nothing" cluster.

We then have the problem of distributed caching, and that's a tricky problem (to make an

understatement), at least if you need real-time consistency. It is so tricky that I have given up on it

for now as far as finding a general solution that can scale up well. However, for specific situations,

we can find good enough solutions. Of course, if we have all Domain Model instances in memory,

there are probably fewer situations where we need to scale out, at least for efficiency reasons. Still,

ifwe do have the problem, it's a tough one to solve in a good way.

Note

The term "shared nothing" cluster needs a short explanation. What I'm aiming at is that

the application servers aren't sharing either CPU, disk, or memory. They are totally

independent of each other, which is beneficial for scalability.

To read much more about this I recommend Pfister's In Search of Clusters[Pfister

Wolfpack].

[Cassio Pinheiro Almeron]

[Cassio Pinheiro Almeron]