"The best code is no code at all. Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options".
Essa e a conclusão do artigo The Best Code is No Code At All escrito pelo Jeff Atwood, co-fundador do Stack Overflow, no blog Coding Horror e representa algo que e muito importante: evitar ao maximo escrever código desnecessario.
O próprio Dijkstra também tem uma frase muito conhecida nesse sentido: "if we wish to count lines of code, we should not regard them as lines produced but as lines spent".
Um dos principais objetivos do Domain-Driven Design e estimular um entendimento profundo do domínio, que e o motivo pelo qual uma empresa existe no mercado, representa a sua proposta de valor, o problema que ela resolve.
A partir desse entendimento e possível decompor o domínio em partes menores, em áreas de conhecimento especificas, que são os subdominios.
Exemplo: E-commerce
Vamos utilizar como exemplo um domínio que todos conhecem bem, o e-commerce e nele podemos identificar diversos subdominios como:
- Catalogo de produtos
- Carrinho e checkout
- Pagamento
- Emissao de nota fiscal
- Controle de estoque
- Operacoes de logistica
- Processo de devolucao
A partir dIsso é possível avaliar dois aspectos a respeito de cada um deles: a complexidade técnica e a diferenciacao que trazem para o negocio.
Classificação de Subdominios
Os subdominios podem ser classificados como: Core, Supporting ou Generic.
Core: O tipo mais importante porque proporciona diferencial competitivo e e onde os maiores esforcos devem ser feitos, proporcionando mais retorno sobre o investimento.
Supporting: Apesar de ter menos complexidade e essencial para o funcionamento do Core.
Generic: Geralmente tem alta complexidade mas pouca relevância estratégica, devendo ser evitado, principalmente em empresas menores, por tirar o foco daquilo que e essencial para a empresa.
Exemplo Prático: Nota Fiscal
Usando como exemplo o e-commerce, todos eles precisam emitir nota fiscal, mas isso Não é algo que traria diferencial estrategico para uma empresa de e-commerce e poderia ser contratado de outro fornecedor ao inves de ser desenvolvido.
Multiplos Core Domains
Uma pergunta que pode surgir e: e se a minha empresa tiver mais de um Core? Isso é relativamente normal, tem empresas que fazem produtos na area da educação, saude e contabilidade, nesse caso são verticais de negocio diferentes, cada uma com seu Core. O mais importante e que o resultado dessas verticais possa ser analisado de forma individual, deixando claro qual e o resultado é a margem de cada negocio.
O Core do E-commerce
No caso do e-commerce, certamente o Core e o checkout, e a coisa mais importante que existe dentro de uma plataforma de vendas e se ele for ruim, se não tiver a possibilidade de aplicar um cupom de desconto, pagar com meios de pagamento diferentes ou de forma parcelada, calcular o frete, resumindo, se ele não tiver tudo aquilo que e necessario ou tiver e não funcionar bem, todo o restante deixa de fazer sentido.
O que adianta uma plataforma de vendas ter a melhor emissao de notas fiscais ou o melhor controle de estoque se ela e ruim no que e essencial, que nesse caso e tudo aquilo que tem relação com a realizacao da venda.
A não ser que você seja o Mercado Livre, a Amazon ou Magalu, recomenda-se evitar ao maximo a implementação de qualquer subdominio do tipo Generic. Isso vai drenar as energias da equipe em algo que apesar de ser importante para a operação poderia ser entregue por diversos fornecedores especializados, por um preço justo e de forma confiavel.
E acima de tudo uma questao de não desfocar e não desperdicar energia e com o tempo que sobra você pode se focar ainda mais no seu Core subdomain e ter ainda mais diferenciacao de negocio.
Domain-Driven Design na Prática
Aplicar Domain-Driven Design não se resume em criar meia duzia de Aggregates, Entities, Value Objects, Domain Services e Repositories, vai muito além, parte do principio que existe de fato um entendimento profundo a respeito do domínio.
Uma vez que a modelagem estratégica tenha sido realizada, ou seja, o domínio foi entendido, os subdominios foram identificados e classificados, e possível definir onde e como serao implementados.
Bounded Contexts
Os bounded contexts, que você pode interpretar simplesmente como um espaco de solução, e o lugar onde o código será escrito.
Enquanto os subdomains existem independente da nossa vontade, já que eles são parte do problema, os bounded contexts representam uma decisão técnica, refletindo o que queremos agrupar e o que queremos separar.
Nesse sentido, quando pensamos em um monolito, significa que a decisão foi de implementar todos os subdomains juntos, na mesma base de código, no mesmo projeto.
Existem sempre vantagens e desvantagens ao criar um bounded context.
Uma das vantagens e que e possível reduzir o acumulo de código e a mistura de responsabilidades, que e um fenomeno conhecido como Big Ball of Mud, mas ao separar precisamos lidar com a complexidade técnica necessaria fazer a integração entre os bounded contexts.
Padrões de Relacionamento
Padrao A - Um para Um: Temos uma relação de um pra um entre um subdomain e um bounded context. Esse pode ser um caminho interessante, mas e bom tomar cuidado para não separar bounded contexts que tem muita dependência e podem tornar a integração muito complexa.
Padrao B - Multiplos para Um: Temos um cenário normal em empresas grandes, com um domínio grande e complexo, onde temos vários bounded contexts para o mesmo subdomain. Isso acontece porque os subdomains acabam tendo muitas especificidades de negocio, com muitas equipes envolvidas e que justificariam essa separacao.
Padrao C - Monolito: Talvez seja o cenário mais comum, e o bom e velho monolito onde agrupamos vários subdomains no mesmo bounded context. Pode ser uma boa forma de começar e ganhar a maturidade necessaria para depois decidir como e a melhor forma de separa-los.
Exemplo de Distribuição
De acordo com o livro Implementing Domain-Driven Design de Vaughn Vernon, e possível ter 5 subdomains (Product Catalog, Orders, Invoicing, Inventory, Shipping) distribuidos em 3 bounded contexts (e-Commerce, External Forecasting e Inventory).
Conclusão
A modelagem estratégica aumenta muito as chances de sucesso por meio do entendimento do domínio e de como ele se divide em subdominios, permitindo delegar subdominios do tipo Generic para outros fornecedores e com isso focar no que realmente tem mais diferencial estrategico para a empresa.
Além disso, os bounded contexts são essenciais para distribuir a complexidade em soluções tecnicas diferentes, sendo inclusive um excelente caminho para a definicao de uma arquitetura de microservices, fazendo com que as equipes trabalhem de forma mais eficiente e evitando que conceitos de domínio se tornem mais acoplados e complexos.