Boa tarde.
Estou lendo o livro do Eric Evans acerca de DDD, ele fala de travessia…
Estou lendo em português, mas não entendi muito bem esse termo… se encontra na página 140:
Na verdade, deparei-me com um projeto em que a equipe estava tentando o acesso a objetos através de criação ou de travessia! …
O que seria travessia??
Você pode imaginar os objetos e suas associações num software como um grafo. Toda vez que você pula de um objeto pro outro, ou caminha no grafo, está fazendo uma travessia.
foo.getAbc(); é um exemplo de travessia. Esse termo não faz muito sentido em português. O termo em inglês é traversal, e é usado para indicar que você está “passeando” no grafo.
A propósito, esse livro é ótimo. Recomendo outros 3, se não tiver lido ainda: Clean Architecture, Implementing Domain Driven Design e Patterns of Enterprise Application Architecture.
Então quando eu faço…
carro.getMotor().getPistoes().getAlgumaOutraCoisa();
Então esse é um traversal, e provavelmente um traversal desse tamanho ou maior não é tão elegante?
A leitura desse livro é muito densa, preciso ler e ler novamente… 
Exatamente. Não é elegante mesmo. Numa solução mais elegante, você provavelmente nem precisaria descer tão fundo no objeto assim, pois a própria interface do objeto teria algum método para fazer o que você quer fazer.
Outro lugar onde esse tipo de “travessia” mais profunda acontece é quando você quer mostrar algo na UI. Para isso, existe um outro padrão chamado Command Query Responsibility Segregation (ou CQRS). A ideia é que você tenha duas interfaces na sua aplicação, uma para executar comandos e outra para buscar dados. A segunda é utilizada para popular a UI com dados, por exemplo.
Enfim, como você falou, a leitura desse livro é muito densa. Eu já li umas 3 vezes e toda vez aprendo coisa nova. Um ponto muito importante de salientar, que o próprio Evans lembra sempre, é que não é prático aplicar DDD em softwares simples. Só vale a pena pagar o preço de implementar DDD quando o domínio do problema que se tenta resolver é relativamente complexo. Para projetos simples (só CRUD), não há nada de mal em fazer algo como uma UI Inteligente, por exemplo (lógica de negócio na UI ou nos controllers).
Com o tempo você vai pegando os conceitos. Lê outros livros depois volta pra esse. O importante é não desistir.
Sim entendi.
Eu já criei aplicações utilizando Script Transaction, separando as regras de negócios em services e comecei a pesquisar e descobri sobre modelos anêmicos, e sempre que estudo algo, gosto de pegar a essência da coisa, e sempre ouvi que DDD é o retorno à OO pura… Eu quero muito aplicar DDD rs… mas vou seguir seuconselho, vou partir pra outro e depois voltar pra esse.
Acho que o ponto central do DDD é que você tem que encontrar um design de classes que reflete o seu modelo de domínio. Se o problema que você tá tentando resolver é simples, é contraprodutivo ficar tentando complicar com um design de classe elaborado.
As vezes o problema que você tá tentando resolver é simples e um modelo anêmico resolve (um CRUD simples, por exemplo).
O problema é quando você tem um domínio complexo e usa os objetos só como estruturas de dados. Aí a lógica fica espalhada no código e dar manutenção é um lixo.
Aplicar DDD é difícil. Toda vez que você introduz um conceito novo, tem que adicionar várias classes no projeto. Esse é o preço a se pagar. Contudo, o resultado é que você fica com um código muito mais fácil de dar manutenção.
Um exemplo legal é um guarda-roupas. Você pode otimiza-lo para duas coisas: inserção de roupas ou busca de roupas. Se você quer otimizar para inserção, é só jogar as roupas lá dentro de qualquer forma. Vai ser muito fácil inserir, mas vai ser horrível buscar. O outro caso, a otimização para busca, é você guardar cada peça no seu devido lugar. Vai levar mais tempo para guardar as roupas, mas vai ser bem mais rápido para achar uma peça específica. DDD é otimizar para busca 