This content originally appeared on DEV Community and was authored by joão burgarelli
Antes de tudo, ‘e importante salientar que o intuito desse artigo nao ‘e ser objetivo e sim evidenciar com um exemplo de uma parte da aplicacao do TCC Salus foi impplementado utilizando DDD (Domain Driven Desing) e Clean Architecture.
Por que DDD e Clean Architecture?
‘E importante dizer que Clean Architecture e DDD sao coisas distintas. Enquanto Clean Architecture esta relacionado a arquitetura de software ea capcidade de organizar o código de modo que ele seja independente, DDD esta relacionado a design de software ea modelagem e entendimento profundo do domínio do negócio, sendo o principal objetivo 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 frameworkd utilizado, provedores de cloud, bibliotecas relacionadas a autenficacao, QUALQUER COISA, isso seja algo natural, sem comprometer a eficiência e funcionalidade do sistema, promovendo flexibilidade e facilidade na manutenção.
This content originally appeared on DEV Community and was authored by joão burgarelli