O que eu entendo sobre design orientado por domínio
On Novembro 15, 2021 by adminDDD 101
Quanto maior o projeto, mais difícil é mantê-lo. Uma forma de ajudar nisso é quebrar o aplicativo em áreas menores de acordo com suas regras de negócio, conhecidas como domínios.
Basicamente, um domínio é uma área de conhecimento, seja público, como as regras do xadrez, ou privado, como as regras de negócio de uma organização sem fins lucrativos .
Um domínio complexo é provável que use o conhecimento de outros domínios. Por exemplo, uma NPO que ensina xadrez online saberá sobre xadrez, ensinando através de plataformas online, e, mesmo que não seja cobrado como estudante, sobre suas finanças.
Cada subdomínio do seu domínio é conhecido no DDD como contextos delimitados, cada um tem seu próprio modelo do mundo construído com unidades de código especializadas, conhecidas como blocos de construção. Aqui vou focar em entidades e objetos de valor, ambos podem ser referenciados como objetos.
Entidades são objetos destinados a serem únicos dentro do domínio. Isto é conseguido usando uma ou mais propriedades para identificar uma determinada entidade. Por exemplo, dois usuários usando o mesmo nome em um sistema sempre terão emails diferentes porque os emails não podem ser repetidos – na maioria das vezes, as entidades são diferenciadas por um id, e às vezes por uma combinação de propriedades.
Objetos de valor, por outro lado, não têm uma identidade, portanto apenas suas propriedades podem ser usadas para distinguir entre duas instâncias. Pegue por exemplo dois peões (a ficha de xadrez), eles parecem iguais se vêm do mesmo jogo e têm a mesma cor, então não importa se você trocá-los por aí. No DDD, os objetos de valor são imutáveis, então é mais fácil raciocinar com eles.
Integridade dos dados
Um contexto limitado não expõe todos os seus objetos para garantir sua integridade de dados. Em vez disso, expõe algumas raízes agregadas como uma espécie de interface pública para si mesmo.
Um agregado nada mais é do que uma entidade composta de outros objetos. Para ser mais preciso, um agregado é um agrupamento de objetos associados que tratamos como uma unidade ao alterar dados.
Em termos práticos, os agregados assumirão a forma da estrutura de dados conhecida como árvore. E por essa razão, todos os agregados têm uma raiz.
O único membro de um agregado a que outros objectos se podem referir é a sua raiz, e por isso é isto que expomos. Isto é feito assim porque impede que outros objetos ajustem os dados de uma forma que o agregado não possa controlar.
Importante para deixar claro que um contexto limitado pode usar muitos agregados mesmo quando sua raiz não está diretamente exposta ao mundo exterior.
Lidando com múltiplos contextos limitados
Mas as coisas podem ficar mais complicadas, certo? Cada contexto delimitado obtém um modelo ligeiramente diferente dos mesmos objetos, tendo diferentes propriedades e comportamentos. Então um usuário em um contexto de jogo pode ter uma propriedade para lidar com sua pontuação que em um contexto financeiro é irrelevante e, portanto, não existe.
E isso não é tudo. Também é possível que um conceito de domínio, representado como uma entidade em um contexto limitado, seja representado como um valor-objeto em outro, ou simplesmente seja completamente omitido.
Por exemplo, enquanto o contexto de ensino requer que os professores sejam representados como entidades para que possam ser atribuídos aos alunos pelos seus ids, o contexto financeiro prefere ver “professor” como um valor para a propriedade de posição da entidade empregada.
Alguns outros blocos de construção DDD são serviços, repositórios, fábricas e eventos. Vou tentar descrevê-los brevemente.
Serviços são capacidades de um domínio que não se encaixam naturalmente em entidades nem em valores de objeto. Cuidado que eles são serviços de domínio, não serviços de aplicação ou infra-estrutura.
Repositórios são pontes para unidades de armazenamento – olá CRUD!.
Fábricas são métodos para criar objetos de domínio para que eles nunca tenham valores inválidos. Esta parte é o que me fez começar a pensar em testes orientados a produtos.
Os eventos são objetos que representam algo que aconteceu no domínio – seus especialistas se preocupam com eles. Grandes oportunidades para criar uma aplicação orientada a eventos .
Embora eu não me lembre de Evans afirmar isso, contextos delimitados são uma boa oportunidade para dividir seu código em microserviços, onde cada serviço é um contexto por si só. O primeiro passo pode ser uma divisão “virtual” onde cada contexto é colocado em um módulo diferente no mesmo aplicativo, e então se você detectar que eles estão realmente isolados, mova-os para outros diferentes.
Uma linguagem para governá-los a todos
Uma das primeiras coisas que as pessoas aprendem quando estudam DDD é que seu sistema deve ser descrito por uma linguagem ubíqua. Ou seja, devemos escrever código usando os mesmos verbos (para métodos ou serviços) e substantivos (para objetos) que os especialistas do domínio usam quando falam conosco.
Código escrito como este tem a vantagem de fechar a lacuna de comunicação entre desenvolvedores e especialistas quando estão falando, mas é uma simplificação excessiva da vida real, então eu pessoalmente o uso como uma diretriz, mas não uma solução final.
Eu guardei para o último porque, para mim, o mais importante do DDD normalmente não é lido, pois está na parte “complexa” do livro.
Recentemente aprendi que o próprio autor disse que a ordem em que ele apresenta as coisas no livro não é a melhor, e o que descrevi aqui está mais próximo do que teria sido ideal 😍. Ouvi-o num podcast referindo-se a este
Deixe uma resposta