Vou escrever uma série de posts sobre DDD, este é apenas suma introdução.

Foi-se o tempo que o desenvolvedor ouvia uma demanda de seu chefe, pensava em como implementar, e logo codificaria.
Isso ainda existe? Sim, existe.
Porem, vamos pensar em quantas vezes isso gerou mal entendimento do que foi solicitado. Quantas vezes levamos bug para produção, por não pensar nos efeitos colaterais (muitas vezes até conseguimos prever a maior parte deles).
Entre outros problemas, que no fim das contas, geram custo / prejuízo para quem paga o projeto.
Mas quem está errado?
O cara que solicitou o requisito (se é que muitas vezes pode ser chamado de requisito) e não entendida os impactos técnicos?
Ou o desenvolvedor, que não soube expressar o quão complexo seria implementar tal funcionalidade, e que não fazia sentido técnico (talvez comercial).
Segundo o site base2, em 2016 houve um prejuízo de US$ 1.1 trilhão, por conta de bugs em sistema no geral.
Não estou dizendo de quem é a culpa, mas tentando colocar que existe mecanismos para minimizar os danos do lado técnico e comercial, ou seja, utilizando DDD (Domain Driven Design – Projeto Orientado a Domínio).

Aplicar DDD em um projeto traz muitos desafios, como podemos justificar o uso do mesmo?

Como o desenvolver vê um projeto com DDD: QUALIDADE DE SOFTWARE
Como a empresa vê quando alguém sugere DDD: MAIS CUSTO + MAIS TEMPO.

O que custa mais caro?
Pagar o prejuízo do bug de software (e não estou mencionando sobre a imagem da empresa) ou pagar por um projeto que vai se estender por mais tempo de desenvolvimento e provavelmente envolver mais pessoas.
E nem estou mencionando TDD, e sim DDD, ou seja, estou considerando como bug, apenas mal entendimento.

É evidente que não é necessário fazer 100% dos projetos em DDD, mas um projeto complexo, creio que devemos cogitar a ideia.

Um dos maiores desafios ao usar o DDD, pode ser o esforço necessário para pensar sobre o domínio de negócio. Levantar conceitos e terminologias (linguagem ubíqua), para conseguir conversar com o especialista de negócio, de formas que ambos tenham um entendimento pleno. Para isso é necessário que o desenvolvedor pense de forma de diferente, para criar soluções para o domínio. Afinal de contas, muitas vezes, nós desenvolvedores, não entendemos do negócio em questão, para qual estamos programando inicialmente, daí se faz necessário o especialista do domínio (quantas vezes não conversamos com alguém que apensar é dono do negócio, e não entende de fato).

O que ganhamos com o uso de DDD

A ênfase do DDD é investir nossos esforços no que é mais importante para o negócio. Há um grande valor de negócio, quando a empresa desenvolve uma compreensão mais profunda do negócio.
Não espere encontrar um cenário que todos os especialistas de negócio concordem com as terminologias. Devemos conversar muito com os especialista de negócio antes de qualquer coisa.

Espero ter ajudado!
Até a próxima!

Publicidade