Domain Driven Design
Também conhecido como DDD, Domain Driven Design está bem alta nos tempos mais recentes pelo apelo a maior aderência do sistema a lógica de negócio. Mas mais do que uma receita, ou técnica, DDD é um conceito. Aplicar DDD é mudar a maneira de pensar em relação a modelagem (Design) do modelo de domínio. Trata-se de um maior foco no problema que o cliente quer resolver, e basear os resultados atingidos e caractrísticas do sistema com base em feedback do cliente.
A idéia não é nova, e a semelhança com as práticas ágeis é muito clara, por isso DDD veio a tona nos últimos tempos, embalado com a onda das metodologias ágeis.
Conceitos
Como foi dito anteriormente, e como é pregado no livro do Eric Evans, dito pai do DDD, se trata de uma maneira de pensar mais do que uma receita ou metodologia. Os primeiros capítulos do livro citam casos em que a modelagem da aplicação pode levar em conta um melhor entendimento do negócio, e como um modelagem muitas vezes natural e intuitiva do ponto de vista técnico pode trazer problemas futuros para a aplicação.
Um exemplo interessante presente no livro, é o exemplo de um programa para modelar um circuito eletrônico. Em tal exemplo é primeiro abordado o modelo convencional de modelagem e organização, assim como alguns padrões de projeto pensando mais do ponto de vista técnico da aplicação. Porém componenentes eletrônicos, portas lógicas por exemplo, possuem uma certa intelgência imbutida. No modelo convencional o modelo de negócio é uma camada burra da aplicação, onde somente são armazenados os dados referente ao domínio. Tal abordagem traz problemas quando é necessário simular uma execução do circito eletrônico, pois seria necessário guardar tal inteligência na camada responsável por gerenciar os componentes, tornando a aplicação mais complexa, e concentrando o conhecimento de negócio em um único lugar.
A idéia nesse caso, é tornar o modelo do domínio mais inteligente, e passar a responsabilidade de entender seu funcionamento para as entidades, espalhando mais o conhecimento do negócio, e possibilitando outras partes da aplicação de terem acesso a este mesmo conhecimento somente através do domínio.
Não focarei nesses exemplos nesse post, pois o intuito aqui é mais uma introdução aos conceitos básicos e a nomenclatura muitas vezes empregada em DDD. Vamos ver algumas definições.
Domain
Um Domain (domínio) nada mais é do que uma descrição de um conceito de negócio, contendo as informações que o modelo necessita e o comportamento do modelo. Um exemplo clássico é uma aplicação que precisa gerenciar usuários. Em uma aplicação como esta, usuários carregam informações, podem ser listados, criados, deletados, editados, associados com outras entidades, etc. Toda essa lógica determina um domínio. Então diferente de uma arquitetura convencional MVC por exemplo, onde o modelo seria os dados do usuário, o controller seria responsável por associar e e gerenciar os usuários e a view se encarregaria de mostrar o usuário, em DDD essa lógica faz parte do domínio de usuário.
Parece um pouco overkill concentrar tantas responsabilidades em um único ponto, mas mais forte do que lógica da aplicação, modelar o sistema dessa forma concentra a lógica de negócio em um único lugar também. Com isso podemos acessar o domínio de usuário em qualquer lugar do sistema, e o comportamento será o mesmo em todos os lugares, facilitanto assim quando o modelo de negócio exigir que seja feita alguma alteração no comportamento do domínio de usuário.
Domínio é o centro das atenções em DDD (óbvio), mas já é possível perceber que tanta responsabilidade em um único lugar pode dificultar criação e manutenção de tais domínios. Por isso que existem as outras definições em DDD, para facilitar a manutenção e a modelagem do domínio.
Factory
Factories são responsáveis por criar novos Domains.
Muitas vezes os domínios são complexos, e precisam do auxílio de outras classes de negócio para poder se comportar da maneira esperada. Pensando nesse ponto, os domínios podem ser criados através das Factories, delegando a responsabilidade de preencher e configurar o domínio, deixando para o domínio focar mais na parte de lógica de negócio.
Essas factories podem ser modeladas de acordo com as necessidades da aplicação. O que DDD prega é que se mantenha o conceito, para que caso os domínios precisem ser alterados, de maneira que alguma pré-configuração, ou uma nova entidade de negócio comece a fazer parte do domínio seja incorporada, fique fácil dar manutenção e testar esse novo comportamento.
Porém Factories ainda assim podem acabar tendo muitas responsabilidades no que diz respeito a organização do domínio, em termos de armazenamento de dados mesmo, ou seja, muitas vezes uma representação do domínio como entidade pode ser bem complexa, pois a representação pode ter uma série de dependências para outras entidades e assim por diante, todas dentro do mesmo conceito de domínio.
Pensando nesse possível problema, existe uma outra definição em DDD.
Aggregate
Um Aggregate, como o próprio nome traduzido diz, é um agregado de entidades do domínio.
Sua responsabilidade é respresentar um conjunto de outras entidades que identificam a entidade do domínio. Uma maneira mais prática de se pensar, é que um domínio utiliza um Aggregate para criar a entidade que representa o domínio. A idéia é concentrar a responsabilidade pela entidade do domínio no aggregate, tornando mais fácil a manutenção e alteraçao do modelo de negócio.
Tanto a factory, quanto o aggregate pertencem ao domínio, portanto são características tranparentes ao usuário do domínio, ou seja, os domínios interagem entre si apenas pelas caracterísiticas expostas pelos próprios domínio.
Conclusão
DDD não é a solução para todos os problemas de modelagem de regra de negócio, afinal a modelagem depdende muito mais das pessoas do que do conceito em si, mas é uma maneira mais concisa de pelo menos dar ao sistema uma cara mais parecida com o modelo de negócio, e criar a famosa Ubiquitous Language, onde programadores e pessoas de negócio conseguem se entender melhor.
Por @Gust4v0_H4xx0r
, seguem algumas informações sobre o livro.
) daquela chamada, portanto nele estão setados a view a qual a chamada está associada, e todos os atributos de modelo que devem chegar até a view. Tais atributos são guardados como em um Map associando chaves e valores. Veremos que esses valores ficam disponíveis em nossa view e podem ser usados nos JSPs da aplicação, mas agora vamos ao método do controller:
Qual você vai escolher? Escolha a que te faz mais feliz.
