Minha visão de desenvolvedor sobre Domain-Driven Design (DDD)

Fala galera, tudo bom?

Recentemente tenho lido muitos textos sobre DDD e percebi que muitas pessoas (principalmente devs) ainda ficam bastante confusas sobre o que realmente é o DDD, seus pontos fortes, suas fraquezas. Talvez isso aconteça pela enorme variedade de visões que a gente encontra por ai e pelo fato do DDD usar alguns termos que fazem parte do dia a dia de um desenvolvedor que possuem significados totalmente diferentes.

A primeira coisa que devemos ter em mente é: Não, DDD não vai salvar sua vida, e em alguns casos vai somente piora-la, a ponto de você ter que reescrever todo o seu código depois de um tempo.

Me perdoe se fui muito direto, mas é preciso dizer isso. Prometi a mim mesmo que não utilizaria essa frase mas não aguentei então la vai: “Não existem balas de prata”.

Por isso, use-o apenas em softwares complexos, em outras palavras, não use uma bazuca para matar uma mosca! (eu sei, mais um clichê).

Outra coisa que gostaria de informar logo no inicio: Não, DDD não é só uma maneira de arrumar os diretórios do seu projeto.

Antes de começarmos a desmembrar o DDD vamos entender o que é BBM (Big Ball of Mud), também conhecido como SPAGHETTI CODE.

Vou ser bem breve aqui e citar o Wikipedia:

“A big ball of mud é um sistema de software que não possui uma arquitetura perceptível. Embora indesejáveis do ponto de vista da engenharia de software, tais sistemas são comuns na prática devido a pressões de negócios, rotatividade de desenvolvedores e entropia de código. Eles são um tipo de anti-padrão de design.”

Ou seja, basicamente um Spaghetti Code ganha vida com o Inicio da criação do código sem um solido estudo das regras de negocio e dos problemas a serem resolvidos.

Para saber mais clique aqui.

Agora que ja sabemos o que é um Spaghetti Code, vamos ao que importa!

Vamos falar de Domínio

Para começar gostaria de deixar algo bem claro, Domain x Domain Model.

Domain = Seu Negocio

Domain Model = Código que representa esse negocio

DDD x Tempo de Desenvolvimento

Infelizmente trago aqui uma verdade que muitos não querem aceitar.

Sim, DDD aumenta, e muito, o tempo de entrega de um software e vou te explicar o motivo.

O DDD te obriga a seguir padrões que muitas vezes vão resultar em mais classes, mais complexidade (a primeira vista), mais entidades, mais serviços, que no final, irão te ajudar a longo prazo (manutenibilidade), mas se você precisa de algo pequeno, que cada segundo faz diferença para sua entrega e você não esta preocupado com a manutenção do seu software, não use DDD.

Tópicos do DDD

O DDD é divido em 2 grandes tópicos:

• Estratégico
• Tático

Reparou q eu citei o estratégico primeiro? Então, não foi por acaso, não comece a aplicar DDD pelo Tático (criação de Entidades, Repositórios, Objetos de Valor e etc). Gaste tempo no Estratégico pois é nele que sua arquitetura será definida!

Estratégico

Antes de começar a falar da parte estratégica do DDD, gostaria de reforçar um conceito muito importante nessa etapa, o de Domain Experts.

Domain Experts são pessoas com bastante conhecimento do problema a ser resolvido naquele domínio especifico. Podemos dizer que hoje os Product Managers fazem esse papel, mas não se limite a eles, estou apenas tentando criar um rápido entendimento do termo.

Mas o que eu, desenvolvedor, tenho a ver com a área de negócio?

E a resposta é simples, TUDO!

Desenvolvedores tem sim que entender do negócio, e para que isso acontença deve existir uma intensa interação entre os devs e os DEs.

Deixo aqui um aviso para os devs: Antes de sair codando, pare, pense se realmente aquela feature faz sentido para aquele domínio, discuta com os DE se existe uma maneira mais simples, questione. Não aceite de primeira uma solução dada por DEs, é seu papel entender realmente o que você vai criar!

Hmm faz sentido, mas como vou fazer com que os DEs entendam uma linguagem técnica e eu entenda a linguagem de negócios?

É exatamente ai que entra a Linguagem Ubíqua (Ubiquitous Language)!

Mas antes de começar a falar da linguagem ubíqua quero te mostrar uma coisa muito importante.

Está percebendo que o DDD está diretamente ligado com os princípios do Manifesto para o desenvolvimento ágil de software?

Quando falamos da forte interação entre os desenvolvedores e os Domain Experts estamos fazendo referência a 2 dos 4 princípios do manifesto, e são eles:

• Indivíduos e interações mais que processos e ferramentas
• Colaboração com o cliente mais que negociação de contratos

Com isso em mente, vamos falar mais da linguagem ubíqua.

Ubiquitous Language

A partir de agora não existem mais a linguagem de negócio (Domínio) e a linguagem de desenvolvimento. O time irá falar a mesma lingua!

Digamos que você esta inserido em um domínio imobiliário onde os DEs utilizam o termo CASA e os devs usam o termo APARTAMENTO (inclusive no código). Ja conseguiu imaginar a confusão nas reuniões? E para explicar isso para as novas pessoas que estão chegando no time?

Pois é.

Além de termos simples, devemos transparecer em nosso código as ações que são utilizadas pelos DEs também.

Acho que fica mais fácil de explicar isso com código!

• Exemplo ruim de código:

casa.setLocatario(usuario);

casa.setImobiliária(Imobiliária);

casa.setDataDeInicio(LocalDateTime.now());

• Exemplo bom de código:

imobiliaria.alugarCasa(locatario, casa, dataDeInicio);

Reparou outra coisa no código acima? Isso mesmo DDD tem TUDO a ver com Clean Code e alguns padrōes.

KISS: Keep it simple stupid

YAGNI: You ain’t gonna need it

DRY: Do not repeat yourself

TDA: Tell don’t ask

SoC: Separation of Concerns

Não irei explicar cada um desses padrōes, porém deixo aqui um link muito interessante!

Está percebendo que o DDD nada mais que é a utilização de vários conceitos ja existentes porém de uma maneira simplificada?

A conclusão efetiva vai nos levar ao próximo passo da nossa jornada, que é a divisão de contextos, ou seja, faremos agora o famoso Dividir (seu domínio) para Conquistar.

Sim, o DDD também defende que você tenha contextos totalmente limitados e independentes, para que sua arquitetura seja a mais limpa possível e conseguimos fazer isso usando a abordagem de Contexto Limitado (Bounded Context).

Bounded Context

Acredito que aqui mora o coração do DDD.

Imagine o seguinte:

Você tem o domínio Imobiliária e nele você tem algumas entidades e objetos de valor como por exemplo: Casa e Jardim (calma, mais pra frente eu explico o que são essas coisas).

Digamos que cada Casa possui uma Planta, um numero e um Jardim. Ja o Jardim possui plantas e flores.

Vamos ao código (ruim):

public class Casa {

    private String numero;

    private Planta planta;

    private List<String> plantas;

    private List<String> flores;

    private boolean hasJardim;
 }

Agora digamos que estamos criando um código para validar algumas medidas da casa antes de aprovar uma obra e o desenvolvedor precisar recuperar a planta da casa.

Ao abrir a entidade e ver os métodos da classe Casa vamos achar isso: casa.getPlanta() e casa.getPlantas().

Percebeu que Planta para o contexto de Construção tem um significado e para o contexto de Jardinagem tem outro?

É exatamente ai que o Contexto Limitado entra.

Como estamos falando de 2 contextos, deveríamos ter aplicações independentes para cada contexto (nesse caso Construção e Jardinagem). Ou seja, um domínio pode ser dividido em subdomínios que são separados em contextos.

O Bounded Context ou Contexto Limitado tem 3 pontos chaves:

• Espaço delimitado (External Interface)
• Cada contexto tem sua própria linguagem ubíqua (ubiquitous language)
• Cada contexto tem sua própria arquitetura (Independent Implementation)

Ta pensando a mesma coisa que eu sobre contextos?

Isso mesmo, você pode ter essa estratégia como base para a criação de uma arquitetura de microserviços!

Ao criar um microserviço usando DDD, automaticamente você ja está delimitando o espaço (contexto), criando uma própria linguagem ubíqua para cada microserviço e também ganhando a liberdade de escolher em qual arquitetura você quer construí-los.

Imagine que agora você tem um microserviço representando o contexto Construção criado usando Spring Boot, um microserviço representando o contexto Jardinagem usando o Quarkus e um outro representando o contexto Financeiro escrito em Node.js.

Com isso você agora tem 3 microserviços totalmente independentes, com deploys independentes e códigos independentes, incluindo independência de existência.

Posso ter um Jardim sem uma casa? Se o seu negócio (baseado no seu domínio) disser que agora você pode ter um Jardim em um parque, você não precisa mudar nada nos outros 2 microserviços, ou seja, seus contextos estão totalmente isolados.

Percebeu que acabamos de englobar os outros 2 pontos do manifesto ágil?

• Software em funcionamento mais que documentação abrangente
• Responder a mudanças mais que seguir um plano

Agora com nossos contextos independentes temos a facilidade de responder as mudanças mais rapidamente (deploys independente) e com a linguagem ubíqua, temos um código limpo, oque dispensa aquela extensa documentação.

Segue abaixo uma imagem que define bem essa divisão!

Momento Choque de realidade

Microserviços traz consigo, além de grandes benefícios, muita complexidade para sua arquitetura.

Poderia escrever algumas linhas aqui sobre as desvantagens de se utilizar microserviços porém vou citar um grande autor chamado Chris Richardson:

“Testar um microserviço também é muito mais complexo. Por exemplo, com uma estrutura moderna, como Spring Boot, é trivial gravar uma classe de teste que inicialize um aplicativo web monolítico e teste sua API REST. Em contraste, uma classe de teste semelhante para um serviço precisaria lançar esse serviço e quaisquer serviços dos quais ele dependa (ou pelo menos configurar stubs para esses serviços). Mais uma vez, isso não é ciência de foguetes, mas é importante não subestimar a complexidade de fazer isso.”

Entendeu agora o por que você só deve usar DDD para softwares complexos?

Os drawbacks de seguir sua ideologia são grandes.

Agora com alguns conceitos claros, precisamos criar um diagrama que nos permita visualizar de maneira clara essas divisões e integrações, e é ai que entra o Mapa de Contexto ou Context Map.

Context Map

Esqueça todas aquelas descrições “chiques” sobre context map que você ja leu. Mapa de Contexto nada mais é que um diagrama (ou qualquer outra abordagem) que te permita visualizar com clareza seu domínio, subdomínios e contextos com suas limitações e dependências.

Como mapear dependências?

Simples, podemos utilizar o conceito de Upstream e Downstream para criar um diagrama explicitando a comunicação e influência de cada contexto sobre outro.

Mas o que essas palavras significam?

Upstream: Contexto influenciador

Downstream: Influenciado por uma alteração no upstream

Nada melhor do que um exemplo prático para fixar uma ideia, então vamos lá:

Digamos que estamos mais uma vez no nosso domínio de Imobiliária e temos a seguinte regra:

Sempre que houver uma alteração no contexto Construção, o Financeiro será afetado, porém essa alteração não irá afetar o Jardim, ou seja, na relação entre o contexto Construção com o contexto Financeiro, a Construção seria o Upstream e o Financeiro seria Downstream. Já na relação entre Construção e Jardinagem não existe nenhum tipo de influência, então o diagrama deve relatar uma comunicação simples.

Simples assim!

Agora imagine o seguinte cenário: Você precisa integrar um novo microserviço a um sistema legado e não deseja alterar o protocolo de comunicação do sistema legado (visto que sua manutenção é bastante custosa).

Digamos que esse serviço legado espera receber uma requisição SOAP porém o seu microserviço está enviando uma requisição REST, como fazer?

Uma das maneiras de resolver isso é utilizar o famoso Padrão de Camada Anticorrupção (Anti-Corruption Layer ou ACL)

Mas como implementar isso?

Uma das definições que mais gosto pode ser encontrada num post no site da Microsoft.

“Implemente uma camada ou adaptador entre diferentes sistemas que não compartilham a mesma semântica. Essa camada converte solicitações que um sistema faz para o outro sistema. Use esse padrão para garantir que o design de um aplicativo não seja limitado por dependências de sistemas externos. Esse padrão foi descrito pela primeira vez por Eric Evans em Domain-Driven Design .”

Em outras palavras, utilize um middleware responsável por interceptar e traduzir as requisições entre determinados sistemas.

Legal Julio, mas como posso descrever isso me meu diagrama?

Muito simples, para toda comunicação que utiliza esse padrão, crie uma caixinha escrito ACL junto ao contexto que esta recebendo a requisição.

Segue um exemplo abaixo:

Outro ponto em que o Context Map pode ajudar bastante é na identificação de tipos contextos.

Podemos ter 3 tipos de contextos:

• Core Context
• Supporting Context
• Generic Context

Esses 3 termos irão te ajudar a definir em qual contexto você deve investir mais seus esforços!

Tático

Uma das coisas mais importantes aqui é saber que o DDD não te obriga a seguir NENHUMA TECNOLOGIA específica. Os esforços do DDD são direcionados para a definição de domínios e não para te dizer que Spring Boot é melhor que Quarkus ou que RabbitMQ é melhor que Kafka.

Sabendo disso podemos focar no que realmente importa nesse primeiro passo tático, a definição da arquitetura.

Nesse momento vamos relembrar do Clean Code e usar um princípio que aprendemos no SOLID, o Dependancy Inversion Principle a nível de arquitetura.

Opa, isso te lembra algo?

Isso mesmo, o Dependancy Inversion Principle do SOLID vira Dependency Rule, que é o coração do Clean Architecture. Além disso, o Single Responsibility Principle vira Common Closure Principle em nível de arquitetura, que também é muito útil para nos ajudar nas definições de nossos serviços.

Devemos ter em mente que nossas camadas centrais não devem depender de camadas externas e a imagem abaixo, criada pelo nosso querido Uncle Bob para passar a ideia do Clean Architecture, nos ajuda a perceber isso.

Clean Architcture by Uncle Bob

Uma outra boa prática aqui é escrever adaptadores para que suas entidades são sejam exposta diretamente. (Opa ta vendo outro padrão aqui?)

Exatamente, em grande parte dos casos esses adaptadores serão DTOs. (Data Transfer Objects).

O DTO é um objeto responsável por ser a visão pública da sua entidade para outros serviços, seguindo assim o padrão Dependency Inversion Principle do SOLID.

Digamos que um microserviço envia um novo dado para uma API já existente do seu Serviço Core quebrando o contrato.

Caso não exista adaptador (DTO) para intermediar essa requisição, a entidade estaria vulnerável a alterações externas, ou seja, a adição de um novo dado no contrato resultaria na necessidade de alteração da entidade, mesmo que para o negócio esse novo dado não seja relevante.

Em outras palavras o DTO deixa o domínio totalmente livre de interferência externa.

Provavelmente você deve ter percebido que eu citei entidades acima, e é exatamente do que vamos falar agora, modelagem de domínio.

Segundo Eric Evans, temos 3 opções para modelar nossos domínios e são eles:

• Entidade (Entity)
• Objeto de Valor (Value Object)
• Serviço (Service)

Entidade (Entity)

Antes de explicar entidades quero deixar um pedido, Entity do DDD não tem NADA a ver com a Entity do Hibernate, são conceitos diferentes mas que podem convergir em algum momento.

Agora quero deixar abaixo a definição do Evans segundo Martin Fowler.

“Objetos que possuem uma identidade distinta que percorre o tempo e representações diferentes. Você também ouve esses chamados ‘objetos de referência’.”

Apesar de achar que a explicação acima é bem direta, darei a minha.

Entidades são atores importantes o suficiente para serem únicos e possuirem identificadores, simples assim!

Exemplo: Em nosso contexto imobiliário algumas entidades seriam Locatário, Banco, Casa, Apartamento, etc.

public class Locatario {

    private Long id;

    private String nome;

    …

}

Objeto de Valor (Value Object)

Mais uma vez vou deixar a definição do Evans segundo Martin Fowler, como referência:

“Objetos que se importam apenas com a combinação de seus atributos. Dois Objetos de Valor com os mesmos valores para todos os seus atributos são considerados iguais”

Ou seja, é um objeto em que estamos interessados apenas em seus atributos, não em sua identidade. Por isso Objetos de Valor não possuem identidades e devem ser objetos menos complexos do que entidades e imutáveis, facilitando assim sua criação e manipulação.

Exemplo: Em nosso contexto imobiliário um Objeto de Valor seria a Planta de uma Casa.

//Entity
public class Casa {
    private Long id;
    private Planta planta;
    …
}

// Value Object
public class Planta {
    private List<Double> medidas;
    private int quantidadeDeQuartos;
    …
}

Uma outra coisa muito importante é que quando formos mapear essa entidade e esse objeto de valor no banco, apenas a entidade irá virar uma tabela, os campos do Objeto de Valor estarão contidos na tabela da entidade.

Uma maneira bem simples de mapear esse modelo usando JPA seria o uso das anotações @Embedded e @Embeddable.

Para saber mais clique aqui.

Opa, ja ia me esquecendo, uma Entidade podem ter 0 ou n Objetos de Valor assim como os próprios Objetos de Valor podem ter dentro dele outros Objetos de Valor.

Antes de falarmos dos Serviços vamos entender rapidamente o conceito de Modelo de Domínios Ricos e Modelo de Domínios Anêmicos.

Modelos Ricos e Modelos Anêmicos

Basicamente Domínios Ricos são modelos que tem total controle de seus dados e não dependem de objetos externos para manipulá-los. Já Domínios Anêmicos são modelos que dependem de outras classes para validar seus dados.

• Exemplo de Modelo de Domínio Anemico:

public class Imobiliaria {
    private Long id;
    private Banco banco;

    public setBanco(Banco banco){
        banco = banco;
    }
}

public class ImobiliariaService {
    public Imobiliaria definirBanco(Imobiliaria imobiliaria, Banco banco){
        if(Objects.isNull(banco){
            throw new RuntimeException(“Você precisa definir um banco.”);
        }
        imobiliaria.setBanco(banco);
        return imobiliaria;
    }
}

• Exemplo de Modelo de Domínio Rico:

public class Imobiliaria {
    private Long id;
    private Banco banco;

    public Imobiliaria(Banco banco){
        if(Objects.isNull(banco){
            throw new RuntimeException(“Você precisa definir um banco.”);
        }
     }
}

Como você pode perceber, a validação de criação está dentro do próprio objeto, garantindo assim que você sempre terá uma imobiliária com um banco.

Legal, mas qual a vantagem disso?

Basicamente agora você tem centralizado, isolado e independente, um lugar onde estão todas as regras referentes a essa entidade, ela mesma!

Ou seja, com isso você evita duplicidade de código e aquele famoso “onde é que tá implementado essa regra mesmo?”

E é exatamente esse pensamento que o DDD quer que você tenha!

Agora vamos falar dos Serviços (Services).

Serviço (Service)

Ao falarmos de Service em domínio anêmico (Domain Service nesse caso), o mesmo seria um objeto onde está concentrada a lógica de negócio de uma ou mais entidades. Ao utilizar essa estratégia certifique-se de que seu Service é stateless, ou seja, não guarda estado e possua apenas funções puras.

Funções puras são funções (ou métodos) que não alteram o valor de nenhum objeto externo a ela, evitando assim efeitos colaterais (side effects) e garantem o mesmo output (saída) para determinados inputs (parâmetros de entrada) ou seja, ela precisa ser completamente determinística.

Agora ao falarmos de Services em domínio rico, ele seria uma camada responsável apenas por comunicações externas referentes a um único contexto.

Exemplo: Realizar a comunicação REST com um microserviço de um outro contexto.

Pegando o gancho da comunicação, gostaria de falar agora de Eventos de Domínio (Domain Events).

Eventos de Domínio (Domain Events)

Esse é mais um ponto onde você vai encontrar milhares de definições diferentes e inclusive ganchos para alguns tipos de arquiteturas como Event Sourcing e CQRS.

Porém seguindo o objetivo do artigo, quero manter simples o entendimento das estratégias e ao meu ver a estratégia de Eventos de Domínio nada mais é que um evento disparado a partir de um microserviço do Contexto X com uma informação que possa interessar a outros contextos.

Geralmente essa estratégia é utilizada quando gostaríamos de ter um comportamento assíncrono entre nossos contextos, visto que o contexto responsável por publicar a mensagem não irá esperar um retorno, ou seja, a ação que o consumidor irá tomar baseada nesse evento não importa para ele, por isso é importante pensar sempre em notificar ações passadas.

Nesse caso o Contexto X (publisher) irá publicar um evento/mensagem em um message broker (RabbitMQ, Kafka*, HornetQ, SQS, etc) e os contextos que se interessarem por essa mensagem irão se cadastrar como consumidores (consumers) desse evento/mensagem.

Ao fazer isso o contexto interessado irá receber a mensagem assim que ela for publicada, seguindo o padrão FIFO de queues. (First In, First Out)**.

*Na verdade o Kafka nao é exatamente um message broker, e sim uma Plataforma de Streaming Distribuída (Distributed Streaming Platform). Não entrarei em detalhes pois esse não é o foco do artigo, porém se você quiser entender melhor, veja essa incrível talk falando da definição do Kafka.

**No caso do Kafka são tópicos e o FIFO é garantido apenas dentro da partição, mas não liga pra isso agora, o conceito final é o mesmo e o que interessa aqui é o DDD.

Importante reforçar que cada publicador pode ter 0 ou mais consumidores

Para enteder melhor, vamos a um exemplo prático:

• Ação: Uma casa é comprada.
• Contexto Financeiro: Publicar um evento chamado “casaVendida” para um message broker.
• Contexto Construção: Consumir todas as mensagem do evento “casaVendida” para enviar um email para o comprador oferecendo algum serviço.

Chegamos a uma parte que gera muita polêmica mas é extremamente simples!

Organização de Pacotes e Módulos

Vejo por ai muitos projetos (inclusive criei um monte assim) em que a organização das pastas é baseada em responsabilidades e não em contextos, por exemplo:

• Organização por Responsabilidade

com.juliofalbo.ddd
    .services
    .repositories
    .entities
    .adapters
    …

• Organização por Contexto

com.juliofalbo.ddd
    .construcao
        .services
        .repositories
        .entities
        .adapters
    .jardinagem
        .services
        .repositories
        .entities
        .adapters
    …

Qual ta certo?

Os 2 estão. Isso mesmo, não existe certo ou errado para esse caso!

Acredito que isso seja mais um consenso do time do que precisamente uma estratégia do DDD. Por isso vou dar aqui a minha opinião ok?

Se você tem um módulo ou um microserviço para cada contexto, você não terá esse problema visto que você não terá dois 2 contextos concorrentes (modelo ideal). Então nesse caso a organização por responsabilidade é minha escolha (obviamente).

Mas sabemos que muitas vezes a vida real é outra. Então se em nosso módulo ou aplicação temos mais de 1 contexto (geralmente em aplicações monolíticas), aconselho a utilização da organização por contextos, pois com isso conseguimos nos aproximar mais das estratégias propostas pelo DDD.

Nota: Como dito no início do texto, de nada adianta organizar seus pacotes se você ignorou tudo que leu até agora. Seria a mesma coisa que pedir o combo do Big Mac com Coca Zero pois você quer emagrecer. :)

Agregados (Aggregates)

Mais uma vez algo confuso e que na prática você faz todo dia!

Segundo Martin Fowler, um agregado DDD é um cluster de objetos de domínio que pode ser tratado como uma única unidade. Um exemplo pode ser um pedido e seus itens, esses serão objetos separados, mas é útil tratar o pedido (junto com seus itens) como um único agregado.

Com o exemplo que ele cita fica mais fácil entender o que é um agregado, mas vou tentar simplificar mais.

Um agregado é um conjunto de Entidades e Objetos de Valor que não fazem sentido sozinhos.

Todo agregado possui uma entidade raiz, que será responsável por prover todos os métodos envolvendo as regras de negócio que irão modificar suas entidades filhas ou alterar os objetos de valor. (Seguindo o modelo de Domínio Rico)

Seguindo a lógica do exemplo citado pelo gran master Martin Fowler, não faz sentido um Item de Pedido existir sem um Pedido, logo, nesse caso, o Pedido será a Entidade Raiz enquanto o Item do Pedido será a Entidade Agregada.

Como você pode perceber, ao se utilizar o conceito de Agregados acabamos criando objetos complexos e isso dificulta (e muito) a criação desses objetos. Por isso o DDD defende a utilização de Design Patterns para nos ajudar com a criação desses objetos.

Fabrica (Factory)

As fabricas do DDD nada mais são que a utilização dos Padrões de Criação, como os do GoF (Gang of Four) por exemplo.

Alguns desses padrões são: Factory Method, Abstract Factory e Builder.

Basicamente esses padrões defendem a criação de uma interface ou classe que será responsável por criar o seu objeto.

E sim, eu coloco o builder aqui dentro pois o objetivo final é o mesmo, apesar de ter sua implementação totalmente diferente de uma factory.

Repositório (Repository)

Vou começar aqui com a definição do dicionário da palavra repositório:

“lugar onde se guarda, arquiva, coleciona alguma coisa.”

Como o nome mesmo propõem, nossos repositórios serão responsáveis por armazenar nossas Entidades, Agregados e Objetos de Valor.

Por favor, não confunda o conceito de Repositório de DDD com o conceito de Repositório do Spring Boot.

No contexto do Spring Boot, repositório é a interface responsável por criar a comunicação com seu banco de dados (também conhecido como DAO).

Já no contexto de DDD um repositório pode ser, desde um banco de dados até uma simples lista (coleção) em memória do Java, onde você consegue adicionar seus objetos através do método .add, recuperar através do método .get mantendo o mesmo estado de quando ele foi inserido.

Bom galera, acho que é isso.

Tentei passar um pouco do que aprendi nesses anos atuando como desenvolvedor de software sobre DDD e espero que depois disso DDD não seja mais algo tão obscuro pra você!

Referências

Eric Evans: The Big Blue Book (Domain-Driven Design)

Vaughn Vernon: Implementing DDD

https://www.infoq.com/articles/ddd-contextmapping/

https://agilemanifesto.org/

https://itnext.io/solid-principles-explanation-and-examples-715b975dcad4

https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164

https://clevercoder.net/2018/09/08/clean-architecture-summary-review/

https://en.wikipedia.org/wiki/Big_ball_of_mud

https://martinfowler.com/bliki/EvansClassification.html

https://martinfowler.com/bliki/DDD_Aggregate.html

https://www.infoq.com/articles/ddd-contextmapping/

https://www.nginx.com/blog/introduction-to-microservices/