O Design Tático
Em nossa exploração de DDD, começamos com o Design Estratégico, focando no porquê e o quê fazer. Agora vamos adentrar no Design Tático, onde examinaremos o como. Vamos abordar os principais conceitos de implementação de DDD, discutindo Arquitetura e os Blocos de Construção do DDD.
Neste estágio, vamos explorar as bases do nosso sistema, determinando quais tecnologias adotar (como por exemplo: bancos de dados relacionais ou NoSQL? Microsserviços ou Barramento de Serviços?), e como elas se interconectam.
Arquitetura
Chegou o momento de conceber nossa solução! Já mapeamos nosso domínio e subdomínios, estabelecemos nossa linguagem comum e delimitamos nossos contextos, especificando como eles se comportam e se comunicam.
Agora, precisamos criar o design de nosso sistema, delineando como cada subdomínio será implementado e onde residirão as diversas partes lógicas. O DDD organiza a arquitetura em quatro partes principais:
Camada de Interface de Usuário: Esta camada contém a Interface do Usuário (GUI), interfaces de linha de comando (CLI) e APIs para integração com outros sistemas.
Camada de Aplicação: Nesta camada, encontramos interfaces que mediam entre a camada de interface do usuário e a camada de domínio. Por exemplo, esta camada não contém lógica de negócios, mas monitora e relata mudanças de estado aos níveis superiores. Organiza também as tarefas que o sistema precisa executar. Em algumas arquiteturas, esta camada não existe, sendo integrada à camada de interface do usuário.
Aqui também podemos definir rotinas que são os "gatilhos" para atualizações em massa do sistema, como o exemplo de uma rotina em uma escola que contabiliza faltas dos alunos e atualiza registros centrais da escola.
Camada de Domínio: Conhecida como "o coração do Software", é nesta camada que residem os conceitos de negócios, contendo todas as regras de negócio. Aqui é onde a lógica de negócio é executada, as mudanças de estado acontecem e os registros são criados. Esta camada não armazena os dados, mas fornece as informações necessárias para serem registradas na Camada de Infraestrutura. Aqui encontramos as funções que contêm o "segredo" do nosso sistema, o que é essencial para seu funcionamento e diferenciação. Por exemplo, toda a lógica de notas dos alunos ou a lógica por trás dos planos de aula.
Camada de Infraestrutura: Esta camada possui as capacidades técnicas de suporte às camadas superiores. Aqui residem os meios de mensageria, persistência de dados e é utilizada como o padrão de interações entre as camadas, caso não haja integração direta entre elas.
A mensageria, ou “messaging”, é justamente o sistema que gerencia todas as formas de comunicação entre empresas e clientes.
A figura abaixo mostra um esquema de Camadas do DDD. Fonte: Adaptado por FIAP (2023), de Evans (2003), p. 62
Ao considerarmos nosso Contexto Delimitado, podemos conceber uma arquitetura conforme ilustrado na figura abaixo - "Arquitetura de solução demonstrando as camadas DDD". Fonte: Adaptado por FIAP (2023), de Evans (2003), p. 62
Agora que já temos a representação da nossa arquitetura, podemos começar a edificar, e é aqui que o DDD se distingue de outros modelos.
Objetos de valor (Value objects)
Objetos de valor são reconhecidos por não possuírem identificadores, sendo assim, usamos seus valores para os distinguir um do outro. Cada um é único e imutável (o valor é criado como um todo e não muda depois de sua criação). Vaughn Vernon (2013) oferece uma perspectiva esclarecedora sobre objetos de valor:
- Eles quantificam, medem ou descrevem algo dentro do domínio.
- Podem ser mantidos como imutáveis.
- Formam um modelo conceitual de integridade, consistindo em todos os atributos como uma unidade.
- São completamente substituíveis quando uma medida ou descrição é alterada.
- Podem ser comparados uns aos outros pela igualdade de valores.
Por serem imutáveis, os objetos de valor não podem ser modificados após sua criação. Em vez disso, quando um atributo é alterado, um novo valor é criado. Por exemplo, se inicialmente temos x = 3 e depois alteramos para x = 4, criamos um novo objeto x com o valor 4. O mesmo princípio se aplica aos objetos de valor: em vez de alterar o objeto existente, substituímos por um completamente novo.
Antes de inserir um novo objeto em uma tabela, é necessário verificar se seus valores já existem. Por exemplo, se tentarmos inserir Nome 27, 07/30/001, Rua 97, isso não será possível, pois já existe um registro correspondente. No entanto, se modificarmos um item existente de Nome 3, 07/30/001, Rua 10, um novo item será adicionado à lista.
Essa prática mantém a unicidade da lista de objetos de valor, exigindo uma verificação do objeto antes de sua criação.
Entidades (Entities)
Entidades, em contraste com Objetos de Valor, possuem identificadores e são mutáveis. Cada entidade possui um ID único que nunca será reutilizado por outros, o que torna a imutabilidade impossível, pois as Entidades podem e devem ser alteradas após a criação.
Ao inserir um novo Objeto em uma tabela, ao contrário dos objetos de valor, não é necessário verificar se seus valores já existem. Por exemplo, ao tentar inserir (Nome 27, 07/30/001, Rua 97), este será inserido independentemente de existir ou não, pois será atribuído um novo índice. Quando precisamos alterar um valor, usamos seu índice para localizá-lo na lista e então podemos fazer as modificações necessárias.
Agregados (Aggregate)
Um agregado é um conjunto de entidades e objetos de valor, que mantém relacionamentos entre si e possui um limite que o circunda e define. Uma das premissas fundamentais dos agregados é a garantia de consistência, que assegura a integridade dos dados. Em outras palavras, somente a lógica interna do agregado pode modificar seu estado, garantindo assim a coerência da lógica de negócios que o define.
Nenhum objeto externo ao agregado tem permissão para alterar seu estado. Embora possam ler seu estado, somente o próprio agregado pode realizar alterações. Entretanto, entidades externas podem solicitar a execução de ações que modifiquem o estado do agregado.
É importante ressaltar que entidades externas não podem modificar diretamente o estado do agregado, mas podem solicitar modificações através de interfaces externas. Essas interfaces externas expõem comandos que permitem que um objeto externo "comande" a ocorrência de ações dentro do agregado.
Serviços de domínio (Domain services)
Serviços de domínio são objetos tratados de forma independente, dedicados a lidar com diversas entidades e agregados, sempre que cálculos, execuções de rotinas e outras operações são necessárias.
Event storming
O Event storming é uma atividade interativa na qual um grupo diversificado de pessoas se reúne para modelar o processo de negócio. Semelhante ao que é visto no storytelling de domínio, esta prática visa compartilhar o conhecimento do negócio. Utilizando recursos simples, como cartões coloridos (altamente eficazes!), cada um representando um elemento da história que será contada, nós efetivamente desenhamos nosso processo de negócio.
Para começar, é essencial reunir as pessoas adequadas. Assim como no Domain Storytelling, precisamos selecionar as "pessoas certas" que tenham conhecimento relevante do domínio e que contribuirão para a narrativa. Uma sugestão para a composição da equipe é a seguinte:
Especialistas do domínio Quantos forem necessários para enriquecer a história com seus conhecimentos específicos.
Ouvintes Todos aqueles interessados em aprender sobre a história, geralmente incluindo membros da equipe de desenvolvimento e outros envolvidos no projeto.
Facilitador Responsável por conduzir as conversas, elaborar perguntas pertinentes e manter o foco nos objetivos definidos.
Quanto aos materiais, podemos optar pelo método tradicional de colar papéis coloridos nas paredes. Serão necessárias também canetas coloridas e uma sala espaçosa para a atividade. Alternativamente, podemos adotar softwares de modelagem como o Miro ou o Figma.
Brainstorming
Tudo começa com uma sessão de brainstorming, onde serão relatados os eventos do domínio sendo estudado. Um evento de domínio é uma ação que ocorreu no domínio e esses eventos serão identificados em nossa história como os "post-its laranjas".
Nesta fase, a equipe irá criar todos os eventos possíveis. Um ponto importante a ser observado é que ao descrever a atividade, devemos sempre utilizar o verbo no passado, indicando assim uma ação concluída. Não há uma ordem estabelecida neste momento, apenas vamos adicionando o que for necessário, até que as ideias se esgotem. Isso pode levar o tempo que for necessário, mas um bom indicador para parar é quando as ideias deixarem de surgir. Isso não representa um problema, pois poderemos adicionar mais eventos no futuro.
A figura abaixo representa uma atividade de Brainstorming. Fonte: Elaborado pela FIAP (2023)
Linhas do Tempo
Agora que temos um quadro repleto de eventos, podemos começar a organizá-los criando uma linha do tempo. Essa linha do tempo representa o "caminho ideal", ou seja, como as coisas deveriam transcorrer normalmente. No entanto, é importante lembrar que exceções podem ocorrer e precisam ser tratadas.
É nesta etapa que vamos adicionar alternativas e outros cenários para lidar com essas exceções. Também podemos eliminar duplicidades dos eventos anteriores, remover eventos desnecessários, corrigir descrições inadequadas ou até mesmo adicionar novos eventos que foram esquecidos. Este é o momento de refinar e aprimorar nossa narrativa.
A figura abaixo representa a linha do tempo com os Eventos organizados. Fonte: Elaborado pela FIAP (2023)
Pontos de Atenção
Assim que tivermos uma visão clara do processo de negócio, é hora de começar a análise crítica. Neste momento, vamos identificar nossos pontos de atenção, levantando dúvidas sobre cada etapa, questionando como são realizadas, o que é feito e se há necessidade de mais documentação ou se identificamos algum gargalo.
Esses pontos de atenção serão representados por papéis cor de rosa, dispostos em formato de losango para destacá-los. É fundamental ressaltar que, nesta etapa, os participantes devem contribuir com todas as opiniões que possuem sobre o processo. Qualquer problema, preocupação ou dúvida deve ser registrada como um ponto de atenção, pois pode indicar oportunidades de melhoria futuras.
A figura abaixo representa os Pontos de atenção colocados na linha do tempo. Fonte: Elaborado pela FIAP (2023)
Eventos Pivotais
Ao longo da nossa linha do tempo, identificamos eventos que sinalizam uma transição de fase ou uma mudança de contexto. Esses eventos são conhecidos como eventos pivotais. Eles alteram a forma como operamos e são marcados por linhas verticais em nossa linha do tempo.
É importante destacar que os eventos pivotais são indicadores significativos de mudanças de contexto delimitadas. Eles marcam pontos cruciais em nosso processo, nos orientando sobre as transições e direcionando nossas ações de acordo com as novas circunstâncias.
A figura abaixo representa a Linha do tempo, marcada com a linhas que indicam onde acontecem os eventos pivotais. Fonte: Elaborado pela FIAP (2023)
Comandos
Até o momento, nossa linha do tempo retrata os eventos e nossas preocupações relacionadas a esses eventos. No entanto, os eventos foram desencadeados por ações tomadas por atores específicos. Essas ações são denominadas "Comandos" e são expressas no imperativo, por exemplo:
- Criar atividade (Professor).
- Corrigir atividade (Professor).
- Realizar atividade (Aluno).
- Gravar nota (Professor).
Os atores são listados ao lado dos comandos, porém é importante observar que nem todos os comandos têm atores associados, pois alguns são executados de acordo com as regras do sistema. Os comandos são inseridos em nossa linha do tempo utilizando papéis azuis, enquanto os atores são representados por pequenos papéis amarelos, com uma tonalidade diferente da usada anteriormente. Essa diferenciação facilita a identificação dos atores envolvidos em cada ação ao longo da linha do tempo.
A figura abaixo representa um Exemplo de Comando que cria um Evento. Fonte: Elaborado pela FIAP (2023)
Políticas
Alguns comandos não são executados por atores, mas sim por automações do sistema. Nestes casos, são regras ou políticas de negócio que disparam um comando e geram um evento. As políticas estão diretamente conectadas aos eventos que as ativam e, a partir disso, o comando é acionado. As políticas são representadas em nosso modelo com o papel roxo claro.
Um ponto crucial a ser considerado nas políticas é que estas podem estar condicionadas a critérios limitantes. Ou seja, uma política só é ativada se, no evento anterior, uma certa condição for cumprida. Essa condição pode ser determinada por diversos fatores e serve como um filtro para a ativação da política.
A figura abaixo representa uma Política realizando um comando que gera um novo evento. Fonte: Elaborado pela FIAP (2023)
Modelos de Leitura
Modelos de leitura representam uma visão dos dados, podendo ser relatórios, telas, e-mails, notificações, etc., que os atores utilizam para tomar decisões antes de executar um comando. Os modelos de leitura são representados por papéis verde claro e sempre precedem um comando, pois são consultados pelo ator antes da execução de uma ação. Eles são posicionados antes do comando para indicar essa relação de consulta prévia.
A figura abaixo representa um Modelos de Leitura posicionados na linha do tempo. Fonte: Elaborado pela FIAP (2023)
Sistemas Externos
Em várias situações, temos ações e eventos que podem se originar ou serem enviados para sistemas externos ao que estamos desenvolvendo. Estes sistemas externos estão fora do domínio que estamos explorando. No event storming, esses sistemas externos são representados por papéis rosa.
A figura abaixo representa o Envio de Informações à Sistema Externo, marcado pela seta vermelha. Fonte: Elaborado pela FIAP (2023)
Agregados
Apesar de termos uma visão "completa", ainda precisamos dar alguns passos adicionais. Agora, precisamos organizar nossos comandos e os eventos que eles produzem nos agregados.
Fazemos isso identificando o objeto principal de cada etapa. Por exemplo, vários comandos se referem à atividade, enquanto outros se relacionam com notas e assim por diante. Isso nos dá um indicativo de como vamos agregar nossos elementos.
A figura abaixo representa o Agregados de Notas. Fonte: Elaborado pela FIAP (2023)
Contextos Delimitados
Por fim, vamos combinar os agregados, que tem conexão forte entre si, sejam por políticas, ou eventos relacionados.
A figura abaixo representa o Contextos delimitados conectados. Fonte: Elaborado pela FIAP (2023)
