Projeto de Software
Software geralmente é criado para solucionar um problema específico, seja ele de negócio, social, ou qualquer outra área. Porém, muitas vezes encontramos dificuldades ao mapear esse problema com software. Por isso, existe uma área muito importante de desenvolvimento de software que aqui decidimos chamar de "Projeto de Software", que busca encontrar uma forma melhor para expressar esses problemas reais em software.
Domain-Driven Design
Domain-Driven Design (desenho guiado pelo dominio, ou DDD) é uma abordagem de trabalho em desenvolvimento de software que não é restrita a orientação a objetos, mas é nesse paradigma que as práticas e padrões são descritos.
Nessa abordagem, o domínio é o que mais importa, sendo o núcleo do produto, as necessidades que ele deve atender. Nele estão contidas todas as regras, restrições e ações que realmente refletem o negócio.
Para falar em domínio, ninguém melhor do que o cliente para descrevê-lo, e para que o sistema atenda as necessidades desse cliente, a comunicação é fundamental. Portanto, é necessário que uma linguagem ubíqua, uma linguagem comum, seja construída e utilizada tanto pelo cliente quanto pela equipe de desenvolvimento que estiver trabalhando nesse produto.
Seguindo nessa linha, é importante deixar claro o que deve ser desenvolvido, de forma que tanto o cliente quanto a equipe de desenvolvimento consigam trocar ideias e gerar algum tipo de documentação de todas as regras implementadas no sistema. Em DDD, é indicado que usemos o conceito de desenvolvimento orientado pelo modelo, que pode ser um desenho, um diagrama ou qualquer coisa que facilite a comunicação. Esse modelo deve ser vivo, ou seja, qualquer alteração no modelo deve refletir alteração no sistema, e qualquer alteração do sistema deve ser refletida no modelo. Isso ajuda a guiar o trabalho e facilita a organização da aplicação.
Esse domínio pode ter várias peças, componentes organizados de maneira a executar uma determinada tarefa ou para refletir um processo de negócio usado pelo cliente. Dividir para conquistar é um ditado conhecido. Cada componente deve ter seu contexto bem definido e limitado, deve ser responsável por um único aspecto do sistema. Por exemplo: em um sistema de compras on line temos o contexto do cliente, do pagamento, do catálogo, etc. Cada um desses aspectos da aplicação deve ter uma única preocupação. A isso chamamos de contextos limitados.
É interessante notar que DDD fundamenta várias outras práticas em voga hoje em dia: microserviços, arquitetura CQRS e arquitetura baseada em eventos (Event Driven Architecture) são alguns exemplos.
Mais informações sobre DDD podem ser encontradas nos recursos abaixo.
