Domain Driven Design não é para qualquer time !
Sim, é isso mesmo! Você possa estar se perguntando, o porque? mas fique tranquilo, vamos juntos entender, questionar e argumentar sobre. A minha a ideia com esse artigo é esclarecer alguns conceitos por trás da "metodologia" do DDD (Domain Driven Design) extraído do livro "Domain-Driven Design: Tackling Complexity in the Heart of Software", traduzindo (Domain-Driven Design: Atacando as complexidades no coração do software) - escrito por Eric Evans, publicado em 2003, também muito conhecido como "livro da capa azul" por toda a comunidade de desenvolvedores, engenheiros e arquitetos de software.
Poderiamos começar, partindo da ideia o que é DDD?, porém seria talvez óbvio para muitos de vocês que já tiveram contato com tema, seja através do proprio livro, ou através de artigos, videos, treinamentos, ou palestras; por isso decidir partir da seguinte premissa o que não é DDD:
DDD não é considerado um padrão de projeto (Design Pattern)
DDD não é um paradigma de programação
DDD não tem a ver somente com OO (Orientação a Objeto)
DDD não diz respeito apenas arquitetura e de modelagem de software
DDD não tem a ver com a forma de implementação de um codigo
DDD não é "bala de prata" para solucionar complexidade
Com essas afirmações podemos então delimitar um conceito menos complexo, e assumir uma ótica menos enviezada sobre o assunto. Falo isso porque ao longo dos ultimos anos, venho percebendo o quanto esse assunto tem se tornado um "hyper" perante todo nosso ecosistema de desenvolvimento, e essa é a minha primeira provocação que faço a você, porque este assunto é tão delimitado apenas aos desenvolvedores, engenheiros e arquitetos de software? porque damos uma otica tão enviezada de que esse tema seja assunto apenas dos times de tecnologia? o que sua empresa sabe sobre isso? o quanto seu PO conhece sobre o assunto?, o quanto o seu clinte sabe sobre o assunto? o quanto as outras áreas da empresa estão familiarizada sobre o assunto? Percebam eu que poderia ficar fazendo mais e mais questionamentos sob essa perspectiva. E justamente por isso que afirmo que DDD não é para qualquer time!.
A maior falha de interpretação é justamente achar, que domain driven design está literalmente atraledo apenas ao desenvolvimento, a implementação e a arquitetura de software, o conceito vai muito além, e isso é um fator que muitas vezes passa despercebido para muitos, pois se retomar-mos os primeiros capitulos do livro, podemos concluir que o Evans estava muito mais preocupado com a modelagem do negocio, com a forma de entendimento, em como lidar com as complexidades que existe em cada core business, em como construir uma linguagem especifica para cada contexto, afim de ultrapassar as barreiras e ruidos de comunicação e entendimento. Vejam isso não tem a ver com codigo e sim em como podemos aplicar uma metodologia a fim de abstrair complexidades reais e segregar em camadas de conhecimento e regras que pertencentem ao negócio, ou seja os dominios são uma forma de resposta estas complexidades. E para isso ele constroi toda uma organização e uso de alguns pilares que tornam todo esse processo eficiente que são eles:
A Linguagem Ubíqua*
Os limites de contexto (Bounded Context)*
Mapas de contexto (Context Maps)*
Quando falamos de linguagem ubíqua, podemos dizer que toda a essência do DDD parte deste pilar, porque ele está relacionado a forma de comunicação e entendimento, e isso é um aspecto crucial em qualquer projeto ou organização. A forma como as pessoas que estão dentro de um contexto se comunicam dizem muito sobre a complexidade e funcionamento de um processo, que por sua vez, esta linguagem estará inserida e automatizada em algum software. E a proposta do Evans em seu livro é estabelecer essa "linguagem" é está presente e contextualizado por meio de domain experts (pessoas que detem o conhecimento daquele processo) afim de ser capaz de contruir um dicionário que documente e dê significado para todas as entidades e compartamentos daquele domínio.
Não foi fornecido texto alternativo para esta imagem
Cabe ressaltar, neste ponto que para cada domínio pode haver sua própria linguagem por exemplo:
Em cénário onde meu négocio é uma clinica médica e obviamente dentro desse meu grande dominio clinica, temos nossos subdominios com aspectos e complexidades diferentes, e domain experts distintos com responsabilidades e comportamentos específicos. Podemos ressaltar dois exemplos, dominio Consulta e dominio Financeiro, e dentre esses domínios temos uma entidade que é em comum entre ambos Cliete/Paciente, que depentendo do contexo do domínio eu posso me referir como cliente ou como paciente, ou seja para um medico que está atendendo uma consulta ele visualiza sob a otica de paciente, enquanto um analista financeiro visualiza sob a otica de um cliente.
Com isso podemos seguir com o próximo pilar, que é justamente os limites de contexto (Boudend Context), que é exatamente o entendimento de que um domínio pode obviamente pertencer a outros domínios, no qual denominamos de subdominios. Neste pilar, avaliamos os aspectos e particularidade dos processos, entendedo quais são suas responsabilidades, cabe falar que para identificar os limites, fazemos uso da linguagem ubíqua, porque ao momento que identifico uma nova linguagem que faz referencia a uma mesma ententidade eu acabo de entender que ali existe um novo contexo e obviamente um novo dominio, e assim passo a saber seus limites, como o exemplo citado anteriormente.
Além de sabermos sobre os limites, precisamos entender as relações estabelecidas entre os dominios e subdominios, logo chegamos então ao terceiro pilar que são os mapas de contexto (Context Maps). Saber o tipo de relacionamento nos traz uma visão macro de como se dá a comunicação entre os domínios, nos permitindo caracteriza-los como: Core Domains (Domínios Prinicipais) ou seja os domínios que resolvem as complexidades mais essenciais do négócio, aqui podemos dizer que são os pontos vitais, podemos caracteriza-los também como Generic Domains(Domínios Genéricos) que especificamente não trazem uma regra específica em questão, podendo até nos fazer a refletir se tais contextos poderiam ser externalizados e por fim podemos caracterizar os domínios como Domain Auxiliry (Dominios auxiliares) que são domínios que possuem contexto e regras para suportar o domínio principal. Ficou um pouco complexo, entao vamos exemplificar:
Retomando o caso da Clinica médica, podemos seguir categorizando da seguinte forma:
Bom com isso fechamos alguns dos conceitos que são da essência do DDD, e que necessáriamente nem sempre é aprofundado e estudado de forma criteriosa, os demais termos e conceitos que são abordados vão de encontro para aplicabilidade mais prática e ai sim entra os aspectos técnicos e arquiteturais, dos quais envolvem tipos de implementação e padrões de desenvolvimento.
Mas o que acontece é boa parte das pessoas normalmente pulam ou não dão a devida atenção aos primeiros capítulos do livro, ou não fazem a aplicabilidade destes conceitos. Isso torna-se um problema porque consideram DDD apenas um padrão de arquitetura e implementação focado no desenvolvimento, e o que vimos aqui é justamente o oposto, o DDD prega a visualização e o entendimento do negócio como um todo, fazendo o uso de modelagem, criação de linguagem, de limitação de contexo, entendimento das relações entre os domínios para então seguir com uma abordagem técnica. Por isso novamente questiono como podemos aplicar DDD pensando só em aspectos técnico? Como construir aplicações altamente escalaveis e robustas se não conseguimos entender o comportamento e as relações entre os domínios?, como podemos implementar DDD, se todos os envolvidos no domínio do négocio não conseguem estabelecer um entendimento de DDD?
O ponto principal aqui não é não aplicarmos o DDD, mais sim, fazer uso do jeito errado, equivocado ou superficial, olhado como havia falado anteriormente apenas para alguns aspectos ao invés de uma mudança comportamental e estrutural do time, pois ai você estará adicionando possiveis complexidades que necessáriamente não irão refletir a realidade do negócio e obviamente não estará extraindo o potencial da metodologia. Justamente por esses motivos, muitos times possuem uma dificuldade extrema de implementa-lo e normalmente acabam se frustando durante as tentativas, e desistindo ao longo do caminho.
A minha dica para quem deseja implentar DDD é assegurar inicialmente o quanto o seu time, sua organização e os processos que tangibilizam o negócio estão maduros, pois não adianta o time possuir o entendimento e saber sobre a sua aplicabilidade, se os processos estão ainda embrionários, se ainda não é possivel identificar seus domain experts, se visão ainda não está tão clara para todos os envolvidos, pois nesses cenários DDD não faz sentindo e ai novamente caimos na cilada de que DDD é para qualquer time e deve ser implementado em todo projeto. Outro ponto bem importante, é devemos entender mais sobre modelagem de processo, como o BPM (Business Process Model), e ferramentas como BPMN (Business Process Model Notation). Isso irá trazer mais clareza e amadurecimento, levando o time e a organização para outro nivel e assim estar preparado para começar a implementar DDD do jeito certo!