É muito bom lidar com conceitos bem definidos e claros. O problema é que o desenvolvimento de sistemas é uma disciplina muito recente na sociedade humana. Com isso é muito frequente ver as terminologias brigando pelo coração dos desenvolvedores, até mesmo porque podem vender bons livros. O artigo Estrutura de camadas e Domain Driven Design tenta ir afundo nesse tema para entender se existe uma boa definição para essas camadas.

Aqui no blog temos um conjunto de artigos sobre Domain Driven Design, Kubernetes, Consul, System Design, Devops, e demais temas relacionados à arquitetura de software. Destaco o artigo Domain Driven Design estratégico e Domain Driven Design tático caso queira um pouco mais de detalhes sobre esse artigo, mas não são requisitos para a leitura.

Diferença entre System Design e Arquitetura

Esse é um debate interessante mas me parece que não deveria haver impasse. Na minha visão há também uma questão de tradução para português que nos atrapalha, mas isso também é um problema para os gringos. Design em vários cenários significa projeto e não desenho. Ou seja, system design é um conceito ligado à construção conceitual de um software, com princípios, práticas e afins. Para Eric Evans o Domain Driven é um Design, bem como o SOLID, por exemplo.

Já a palavra arquitetura tem sua origem no grego antigo arkhitekton, que é composto pelos termos “arkhi” (que significa “principal” ou “primeiro”) e “tekton” (que significa “construtor” ou “carpinteiro”). A arquitetura não é abstrata, ainda que possa ser bastante agrangente. Um projeto MVC, por exemplo, diz respeito à arquitetura utilizada, bem como quando se utiliza um Design Pattern do GOF.

Portanto, System Design é conceitual e abstrato, que indica práticas de trabalho; e a arquitetura é clara e estrutural no desenvolvimento. Além disso, arquitetura é uma forma de system design mas o contrário não.

Não! Um projeto com essas pastinhas não é DDD por isso

Não é raro encontrar devs que criam projetos com pastas com os nomes Apresentação, Aplicação, Domínio e Infraestrutura, e por causa disso acham que estão trabalhando com Domain Driven Design. Se você é um desses, vamos entender melhor por que isso não é verdade.

Vamos começar do início: O diagrama a seguir aparece na página 64 do livro ‘Domain Driven Design: Atacando as complexidade no coração do Software‘ (Eric Evans, 2003, segunda edição). O capítulo é o ‘Isolando o domínio’ onde o autor fala sobre as práticas normalmente utilizadas para preservar o domínio da aplicação. Então ele comenta que as aplicações de mercado, de certo modo, sempre têm uma estrutura nesse sentido. Mas que isso não significa que os nomes sejam esses, que geram binários independentes ou que sejam apenas um bloco de código.

Para ser mais claro, é possível que uma camada de domínio seja separada em DTO (Data Transfer Object, com estrutura da entidade) e Business (Camada de negócios, com comportamento da entidade). Ainda assim temos uma estrutura que represente o domínio. E por outro lado, ter uma pasta com o nome Domain pode ter nela um conjunto de entidades que se relacionam sem considerar agregados, value objects, e afins.

Mas além disso embora o livro se chame Domain Driven Design o autor fala muitas vezes no livro sobre Desenvolvimento Dirigido a Modelos. Me parece que isso ocorre por uma mera questão comercial, o nome DDD é mais sonoro. Mas na prática o que interessa é: o modelo do domínio e como isso conecta o time técnico e o time de negócio: o software é apenas uma consequencia estruturada disso. Ter as pastinhas não garante nenhum desses aspectos.

Conclusão

O artigo Estrutura de camadas e Domain Driven Design ajuda a compreender a diferença entre um System Design e uma Arquitetura e por que isso importa na compreensão da estrutura de pastas de um projeto. Além disso o artigo comenta sobre a estrutura de pastas que normalmente utilizam para dizer que trabalham com o DDD. Mas ele acena de que isso não é uma correlação, ou seja, pode ter as pastas e não ter DDD e vice-versa.