Antes de tudo, é importante salientar que o intuito deste artigo não é ser objetivo, mas sim evidenciar, com um exemplo, como uma parte da aplicação do TCC Salus foi implementada utilizando DDD (Domain-Driven Design) e Clean Architecture.
DDD e Clean Architecture?
É importante dizer que Clean Architecture e DDD são coisas distintas. Enquanto Clean Architecture está relacionada à arquitetura de software e à capacidade de organizar o código de modo que ele seja independente, DDD está relacionado ao design de software, à modelagem e ao entendimento profundo do domínio do negócio. O principal objetivo do DDD é criar um modelo que reflita com precisão as regras, comportamentos e interações dentro do contexto da aplicação, centrado no entendimento e colaboração entre desenvolvedores e especialistas do domínio (domain experts).
Pense no software de maneira independente, assim como dirigir um carro. Quando você aprendeu a dirigir, independentemente de qual carro tenha sido, hoje, com esse conhecimento adquirido, qualquer carro que você for dirigir – desde que tenha um banco, pedais para acelerar, frear e embreagem, um volante e um câmbio – você é capaz de conduzir. Ou seja, sua habilidade de dirigir não está vinculada a um carro específico, mas sim aos elementos fundamentais que todos os carros possuem.
No desenvolvimento de software, buscamos esse mesmo grau de independência. Pense, por exemplo, nos bancos de dados relacionais como diferentes tipos de carros. Temos o PostgreSQL, o MySQL, o Oracle Database, entre outros. Inicialmente, você pode optar por um "carro" como o MySQL, mas, se precisar trocar para outro "modelo" como o PostgreSQL, essa mudança deve ser tão simples quanto trocar de carro. A essência de "dirigir" (ou, no caso, gerenciar dados) permanece a mesma, independentemente de qual banco de dados você esteja usando, contanto que os princípios fundamentais sejam seguidos.
Assim como trocar de um carro para outro não muda sua capacidade de dirigir, a troca de um banco de dados para outro não deve mudar a essência do seu sistema. O objetivo é que a transição entre diferentes tecnologias seja rápida e fácil. Isso nos traz independência tecnológica, manutenibilidade e flexibilidade, evitando que todo o sistema dependa diretamente de uma escolha específica de banco de dados, assim como dirigir não depende de um carro específico.
O Domain-Driven Design (DDD) nos ajuda a atingir esse nível de abstração. Ele separa a lógica de negócios do software das decisões técnicas, como a escolha de qual banco de dados usar. Assim como sua habilidade de dirigir é independente do modelo de carro, o DDD permite que a lógica de negócios seja independente da implementação técnica, como qual banco de dados está sendo utilizado. O foco é garantir que, se você precisar trocar de tecnologia, seja um banco de dados, seja o framework utilizado, provedores de cloud, bibliotecas relacionadas à autenticação, qualquer coisa, isso seja algo natural, sem comprometer a eficiência e funcionalidade do sistema, promovendo flexibilidade e facilidade na manutenção. Em resumo, sua aplicação não deve estar completamente vinculada a uma tecnologia, assim como sua habilidade em dirigir não deve estar completamente vinculada a um modelo de carro.
Top comments (0)