Não vejo porque não praticar Domain Driven Design porém estou com pé atrás, entretanto estou disposto a colocar o pé na frente.
Eu desenvolvendo no momento um sistema para controlar estoque de uma empresa, e na verdade já comecei a codificar minhas classes de DAO, Negocio, Controller , e etc. Enfim, estou utilizando arquitetura inspirada em EJB’s (artigo: philip calçado - fragmental), e pelo que sei isso não é bom quando teremos ter um modelo mais rico e que modela de fato a realiadade do cliente, pelo que vi por alto sobre DDD, vi que é uma forma de dar ênfase maior a realidade do negocio focando a principio no DOMINIO do problema a ser resolvido. Entretanto, como estou mau acostumado em usar a arquitetura BOLOVO, como eu faria para usar esse abordagem no meu sistema, visto que estou disposto a refatorar todo meu código.
Os requisitos de analise, diagramas etc,etc que já tenho pode irá mudar tudo?
terei que refinar o modelo denovo, ou fazer, mais uma interação no meu sprint para que eu possa implementar os patterns do DDD, visto que DDD não é só entender de patterns, e sim seguir os principios,um deles linguagem onipresente, e etc…
como ficaria a estrutura do meu projeto? Chamadas etc.etc?
Segue a estrutura atual do meu projeto.
VIEW -> Categoria.jsp, Produto.jsp, EntradaProdutos.jsp e ai vai.
CONTROLLER -> ProdutoController.java, EntradaProduto.java e ai vai.
MODEL -> ProdutoBean.java, EntradaProdutoBean.java
DAO -> ProdutoDAO.java EntradaProdutoDAO.java (tenho interfaceDAO para cada classe DAO, para abstrair o SGBD)
Agora imagina eu representando tudo isso ai no diagrama de classes de projeto, ou seja, se eu for representar o modelo cadê os métodos? fica algo porco eu considero, então me ajudem a transformar isso ai na abordagem DDD pessoal.
Se você quer DDD terá que estudar a literatura indicada já que DDD não é apenas código. Mas, quanto a estrutura de código, para ajudar, dê uma olhada neste exemplo:
Acho que antes de pensar em ser DDD, devemos pensar em ser OO.
Cada classe deve ter estado e comportamento de um determinado conceito. A camada de domínio deve encerrar tudo àquilo que disser respeito ao domínio do negócio… Essas coisas todas!!!
Você não precisa corrigir seu sistema todo de uma vez, mas precisa identificar o que deve ser mudado, planejar e ir fazendo. Acho que vale a pena (Sempre) ler o Refactoring do Fowler.
Sempre, sempre, sempre procure por Patterns para resolver os probleminhas que aparecem, mas não precisa se amarrar a eles!!! Muito cuidado com os patterns daquele catálogo de J2EE, alguns deles nem deveriam ser tão patterns assim, e melecam nosso sistema.
Dê atencão especial à comunicação, tanto a falada e escrita pela equipe em documentação, quanto pela expressada no código. Seja minucioso para escolher nomes, e faça com que os nomes sejam comuns às conversas, aos documentos e ao código.
Enfim, é assim que estou tentando ser DDD aqui, e está dando razoavelmente certo.
sfidencio a primeira coisa que devemos fazer para entender e usar DDD é
“Não ficar perguntando no forúm como usar o DDD” !!!
Isso só prova que seu conhecimento no assunto é ZERO. DDD não é uma receita de bolo que alguém vem aqui e explica em um pequeno post e vc aplica. Estude os conceitos e veja se isto se aplica a você e à sua arquitetura. Existem vários livros…Eu mesmo estou lendo um para entender o assunto e saber pq tanto se fala.
[quote=diogopontual]Eu discordo dessa visão… Acho que explicitar a dúvida fomenta a discussão e acaba refinando a informação e aumentando o conhecimento de todo mundo.
Pedir orientação nunca é ruim…[/quote]
Tirar dúvidas é bom…mas perguntar como usar DDD é abstrato. É como eu chegar em alguém e perguntar como eu faço pra levantar vôo num Boing 747
Esse cara só pode tar de brincadera cmg falando isso
Se o cara veio aqui perguntar é por que tem dúvidas, e uma boa resposta tentando ajudar o proximo seria uma boa.
acho que o guj foi feito para isso, senão, bora todo mundo aqui parar de usar o forum e vamos passar somente utilizar o google e ser totalmente auto didata
pelo - eu o que eu acho
Procure no própio blog, tem vários artigos falando sobre DDD, repositórios e vários assuntos relacionados a erros cometidos quando se utiliza essa abordagem.
