D do DDD

Bem, li muito superficialmente sobre DDD. O livro do Evans ainda está na minha fila.

Sempre tive dificuldade de entender esse Domain, que todos falam pois, para mim, domínio não é tão específico. Pode ser várias coisas, como li, há um tempo atrás, no livro do Page-Jones:

Para Page-Jones, existem 4 domínios: Application domain, business domain, architecture domain e foundation domain.

Para mim, o Domain do DDD se refere ao business domain. Alguém conhece o motivo dessa aparente ruptura entre o Evans e o Page-Jones? O DDD não deveria ser chamado de BDDD?

Esse assunto veio a tona, pois estou preparando um artigo sobre coesão (mixed-instance, mixed-domain e mixed-role) para o meu blog.

Obrigado!

Não deveria ser chamado de BDDD e sim de XDDD ou X = Xumba véia da Telemar/Oi que tem tarifas altas.
Leia meu livro fala muito disso XDDD.

O D é do dominio de negocios.
Ele é um modelo q representa o negocio, por isso a ubiquitos language é muito importante.

O DDD de Evans não se limita a implementação, se expande na comunicação entre a equipe e o cliente, criando uma linguagem unica para comunicação, design e implementação.

[quote=eric_vieira]O D é do dominio de negocios.
Ele é um modelo q representa o negocio, por isso a ubiquitos language é muito importante.[/quote]

Então… essa é a minha dúvida. Porque generalizar domínio? O Page-Jones também fala de Business Domain, mas para domínio, ele dá um conceito que me parece mais amplo. Lembrando que ainda não li o livro do Evans.

[quote=aleck]O DDD de Evans não se limita a implementação, se expande na comunicação entre a equipe e o cliente, criando uma linguagem unica para comunicação, design e implementação.
[/quote]

Realmente, pode ser uma explicação. O conceito geral do Evans é mais amplo (não de domínio), dessa forma, não precisaria explicitar qual o domínio. Já que o DDD foca, pelo que me parece, na melhora do atendimento ao cliente, esse domain, só pode ser o business domain.

EDIT: Deixar mais claro qual conceito do Evans me parece mais amplo.

Estou numa situação contrária a sua. Li o livro do Evans, mas não do Page-Jones.

O Evans tem ciência da arquitetura em camadas, mas todas as classes fora da camada de negócio não são tratadas no livro (deve-se apenas deixar essas classes em um outro package da aplicação). Apenas o domínio de negócio importa pra ele.

Acredito eu, que o domain do Evans seja principalmente o “business domain” e talvez o “application domain”, deixando de fora o “architecture” e o “foundation”.

[quote=Leonardo3001]Estou numa situação contrária a sua. Li o livro do Evans, mas não do Page-Jones.
[/quote]

É porque estou seguindo esta ordem. =)

[quote=Leonardo3001]
Acredito eu, que o domain do Evans seja principalmente o “business domain” e talvez o “application domain”, deixando de fora o “architecture” e o “foundation”.[/quote]

É verdade. Revendo a definição de application domain:

O primeiro grupo de classes, me parece forçação de barra entrar no DDD. Mas o segundo, me parece mais provável, apesar de não me parecer muito claro, pois pelo que entendi, esse grupo de classes funcionaria apenas como uma espécie de roteador, encontrando a BL correta para cada tipo de evento.