Nesse post falo sobre minhas impressões do consagrado livro: DDD Domain-Driven Design, todavia procurarei ser breve para que não te enfade 🤩
Tamanho do Livro
Este livro abrange quase 500 páginas, oferecendo um excelente espaço para explicar um assunto tão complexo quanto DDD.
Dificuldade do Conteúdo
O livro têm dificuldade média para difícil, pode ser preciso reler o conteúdo algumas vezes, se você é uma pessoa que passa muito tempo vendo shorts e/ou imerso no TikTok provavelmente sua capacidade de concentração está um pouco abalada 🙃, contudo lendo mais algumas vezes vai entender também.
O Que Não esperar do livro
Que o livro te ensine a codificar e implantar o DDD, terá alguns exemplos mostrando código, mas apenas para ilustrar o que foi dito. A idéia é ensinar o conceito.
Principais Tópicos
O que é o DDD?
São boas práticas de design de software para, como diz na própria capa do livro, atacar as complexidades no coração do software. Isso irá aumentar a qualidade do software escrito bem como tornando-o fácil de manter, estender e compreender. É uma maneira de pensar que nos ajudará a lidar com domínios complexos.
Domínio
Coração pulsante de um software. É a razão do mesmo existir. É a essência do problema que a aplicação se propõe a resolver, representando a área de conhecimento específica com a qual o sistema lida. (esse seria o domínio principal)
Subdomínio
Divisão do domínio em áreas menores e coesas, facilitando o entendimento e a organização do software.
Linguagem Ubíqua
a linguagem ubíqua é a chave para a comunicação clara e precisa entre todos os envolvidos no desenvolvimento de software. É um conjunto de termos e definições compartilhadas que representam os conceitos-chave do domínio de negócio, garantindo que todos estejam na mesma página. Por ser uma linguagem que todos usam(ou deveriam usar) fica mais fácil entendo o código e os modelos do negócio.
A palavra ubíqua é utilizada com maior frequência pelas pessoas, contudo no livro estará como “Linguagem Onipresente” 🙃
Parece mais difícil do que é. A linguagem ubíqua é a linguagem do dia a dia dentro do contexto do domínio, por exemplo a palavra cliente pode significar aquele que compra em um domínio de varejo, como pode significar aquele que consome um recurso em um domínio de SaaS(software as a service).
Agregados
Agregados são unidades coesas e transacionais dentro do modelo de domínio. Eles encapsulam um conjunto de entidades e objetos de valor(será explicado no próximo tópico) relacionados, servindo como uma “bolha de proteção” para garantir a consistência dos dados e a integridade das regras de negócio. Dentro de cada agregado só pode ter apenas uma entidade raiz. Não entenda que cada agregado tem apenas uma entidade, ele pode ter várias entidades/classes, porém deve ter apenas uma raiz.
Imagine um pedido em um restaurante: o agregado “Pedido” encapsularia a entidade raiz “Pedido” em si, junto com seus objetos de valor e outras entidades relacionados, como “Itens do Pedido”, “Preços dos Itens”, “Descontos”, “Forma de Pagamento”, etc. Essa estrutura garante que todas as informações relevantes ao pedido sejam tratadas como um todo, evitando inconsistências e violações de regras.
Sim, um agregado pode se comunicar com outros.
Objetos de Valor
Objetos de valor são unidades imutáveis que representam atributos ou propriedades específicas do domínio. Eles não possuem identidade(um id) própria e são definidos unicamente por seus valores. Imagine um endereço: ele é composto por rua, número, complemento, bairro, cidade, estado e CEP. Cada um desses elementos contribui para o valor do endereço, mas o endereço em si não possui uma identidade única.
Características dos objetos de valor:
- Imutabilidade: Uma vez criados, os objetos de valor não podem ser alterados. Ou seja seus valores são fixos e imutáveis durante todo o seu ciclo de vida.
- Igualdade por valor: Dois objetos de valor são considerados iguais se seus valores forem idênticos. Ou seja, a comparação se baseia nos valores dos atributos e não na referência em memória.
- Sem identidade: Os objetos de valor não possuem identidade própria. Eles são definidos unicamente por seus valores e não podem ser referenciados por outras entidades.
- Simples: Eles Devem ser simples, porém representar um único conceito ou atributo do domínio. Evite objetos de valor complexos com muitos atributos ou comportamentos.
Conclusão
Eu pensei em escrever mais, mas isso tornaria o texto muito extenso. Além disso, tenho a intenção de despertar sua curiosidade e introduzir o assunto, então paro por aqui. 🙂
DDD Domain-Driven Design transcende a mera codificação. Envolve uma compreensão profunda do negócio, seus processos e as necessidades dos usuários. Trata-se de desenvolver um software que não apenas funcione, mas também dialogue na mesma linguagem do cliente e tenha a capacidade de evoluir junto com a empresa.
Livro Aqui
Acesse nosso canal no Youtube
