Modelagem de Domínio e Arquitetura Orientada a Negócio

Negócio no Centro da Arquitetura - Introdução

Introduzindo o curso de modelagem de domínio e arquitetura orientada por eventos

Olá a todos, sejam muito bem-vindos ao nosso curso de Modelagem de Domínio e Arquitetura Orientada por Eventos. Neste módulo, vamos mudar um pouco nossa perspectiva sobre como construímos software. Historicamente, a área de tecnologia costumava iniciar projetos olhando para diagramas de bancos de dados, frameworks e infraestrutura. Hoje, vamos inverter um pouco essa lógica.

Nosso percurso foi desenhado para conectar a estratégia de alto nível com a execução técnica e analítica, passando por cinco pilares. Primeiro, vamos estabelecer o domínio como centro da arquitetura, entendendo de uma vez por todas por que o software tem um propósito próprio; ele existe exclusivamente para resolver problemas reais e, em consequência, compreender que a tecnologia é o meio e o domínio é o fim.

Explorando DDD estratégico e tático

Em seguida, daremos um passo em direção ao estratégico. Falaremos um pouco sobre DDD estratégico, entendendo como dividir grandes problemas de contextos ilimitados, os bounded contexts, para realmente proteger e proporcionar uma vantagem competitiva para o negócio.

Com o contexto já definido, desceremos um pouco ao nível tático, colocando em prática e discutindo um pouco sobre DDD tático. Aqui é onde entra o código; discutiremos como construir modelos ricos, como encapsular e proteger as regras de negócio.

Conectando através de eventos de negócio

Nosso quarto passo será conectar através de eventos de negócio, arquitetura orientada a eventos, e assim, em consequência, poderemos habilitar produtos digitais modernos.

Ao modelar ações de negócio como fatos imutáveis, como no caso dos eventos, nós facilitamos a comunicação entre sistemas, habilitamos escalabilidade, resiliência e desacoplamento entre equipes. Por isso, é muito importante uma arquitetura orientada a eventos.

Explorando o domínio de dados e data mesh

Por último, levaremos toda a mentalidade além do software operacional. Aqui entra o mundo do domínio de dados, onde falaremos um pouco sobre uma arquitetura de dados, explorando o data mesh (malha de dados) e descobriremos como romper o paradigma de um data lake (lago de dados) centralizado, passando a tratar os dados analíticos processados como verdadeiros produtos. Assim, em consequência, esses dados serão geridos e distribuídos para uma melhor compreensão.

Apresentando o instrutor Fernando Silva

Nosso objetivo aqui não é apenas aprender padrões arquitetônicos, mas desenvolver uma mentalidade para a criação de um software com viés de modelagem de domínio de negócio.

Meu nome é Fernando Silva, sou o arquiteto principal de soluções na GetNet, uma empresa adquirida pelo grupo Santander, trabalhando em soluções orientadas por dados. Também fui articulista na revista Net Magazine, onde escrevi vários artigos. Quem conhece essa revista deve se lembrar; há muitos artigos que escrevi lá. Além disso, fui palestrante no TDC e professor universitário. Tenho mais de 20 anos de experiência trabalhando em arquitetura de aplicações, arquitetura de soluções orientada à engenharia de software e arquitetura de soluções orientada à engenharia de dados.

Vamos começar?

Negócio no Centro da Arquitetura - Domínio - Centro da Arquitetura

Discutindo Arquitetura de Software

Quando começamos a discutir sobre arquitetura de software, normalmente, as primeiras perguntas que nos fazemos são: Vamos utilizar microsserviços? Vamos falar sobre Kafka? Utilizaremos uma plataforma em cloud (nuvem), um provedor de cloud? Vamos usar Kubernetes? Qual banco de dados vamos utilizar? Usaremos um banco de dados relacional? Um banco de dados orientado a transações? Vamos utilizar um banco de dados NoSQL? Qual padrão de desarmamento de paz vamos aplicar no software? No entanto, essas não deveriam ser as primeiras perguntas.

Entendendo o Domínio de Negócio

A primeira pergunta que devemos fazer é: qual domínio de negócio este sistema resolve? Qual problema real estamos tentando solucionar? Quem são os usuários e quais são suas necessidades? O domínio de negócio é, basicamente, um conjunto de regras, processos e conhecimentos que fazem uma empresa existir. Por exemplo, quando falamos de um banco, seu domínio são os serviços financeiros. O e-commerce tem como domínio a venda digital. O sistema de streaming, como a Netflix, tem como domínio a distribuição e consumo de conteúdo. Ou seja, o domínio não é uma tecnologia, uma base de dados ou uma API. O domínio é um problema de negócio que estamos tentando resolver.

Existe um erro clássico que cometemos com frequência na área de tecnologia: acreditar que podemos deduzir como funciona o negócio apenas lendo documentação ou vendo diagramas de bases de dados. No entanto, é importante ressaltar que o domínio não nasce na arquitetura, nem no código. Nenhum arquiteto ou pessoa desenvolvedora descobre o domínio sozinho, isolado em uma sala, com fones de ouvido. Quando tentamos fazer isso, acabamos programando suposições. No design de software, a suposição é o maior inimigo de uma arquitetura sustentável. Se criarmos um sistema complexo, como de contabilidade ou e-commerce, sem nunca termos nos sentado ao lado de um contador, é provável que o sistema tenha processos incorretos ou falhas por falta de conhecimento.

A Importância dos Especialistas de Domínio

Não importa quão limpo seja o código ou quantos padrões de design sejam utilizados, o verdadeiro domínio vive na mente das pessoas que operam a empresa diariamente. No DDD (Domain-Driven Design), chamamos essas pessoas de Domain Experts, ou especialistas de domínio. Quem são eles? São POs, Product Managers, especialistas financeiros, especialistas em logística, pessoas desenvolvedoras, usuários finais. Portanto, nosso papel como profissionais de tecnologia muda aqui. Não somos mais os inventores das regras de negócio, mas sim os tradutores. Precisamos sair das telas, sentar com essas pessoas, ouvi-las de verdade, entender suas dores e, consequentemente, captar o idioma que usam. Nossa arquitetura de software deve ser um espelho fiel do conhecimento que essas pessoas possuem.

Exemplos Práticos

Vou dar dois exemplos práticos que ocorreram na construção de um software junto com uma arquitetura. Um é na área portuária. Trabalhei há algum tempo nessa área, e nossa missão era implementar inteligência de pátio. O pátio é um lugar grande onde colocamos os contêineres que vão embarcar no navio. Quanto melhor a inteligência da operação do pátio, melhor para retirar o contêiner do pátio, colocá-lo no navio e retirar o navio. Consequentemente, o tempo que o navio permanecerá atracado será menor, reduzindo o custo operacional. Se o navio está programado para atracar em um horário determinado, precisamos mover os contêineres e deixá-los preparados para facilitar. O software precisava ter essa inteligência de pátio para saber qual é o melhor lugar para colocar um contêiner, respeitando suas características, como tamanho e peso.

Inicialmente, tivemos várias reuniões com analistas de sistemas, analistas de software, especialistas e operadores de pátio. Quando colocamos o software em produção, na primeira fase piloto, identificamos vários problemas no processo e na arquitetura. Por exemplo, ao determinar um lugar para empilhar os contêineres, dependendo da localização, se havia outros contêineres empilhados próximos, isso criava uma sombra de Wi-Fi, dificultando a conexão. Foi extremamente importante vivenciar a experiência de ir ao pátio e ver a logística de como os operadores, nossos especialistas, trabalhavam diariamente para construir um software mais preciso.

Outro exemplo ocorreu na indústria farmacêutica. Fui chamado para criar a arquitetura de um processo dentro dessa indústria. Nos reunimos com especialistas, operadores e analistas de negócio. Definimos a estratégia, a premissa e as funcionalidades básicas a serem entregues. Uma funcionalidade básica era que, quando ocorresse um problema na máquina, o operador deveria registrar o problema imediatamente. Visitamos a fábrica e, em certo momento, o processo teve um problema. O operador, atento, pressionou um botão de emergência, parou a operação, ajustou o processo e retomou a operação. Percebemos que a funcionalidade de registrar o problema tinha uma dinâmica muito maior do que simplesmente criar um menu de máquina.

A Era da Inteligência Artificial

Na era da inteligência artificial, surge a pergunta: com ChatGPT, Copilot e IA generativa, o DDD pode morrer? A resposta é exatamente o oposto. O DDD nunca foi tão vital para a IA. A IA é excelente em gerar código rapidamente, mas gera aquilo que pedimos. Se não entendermos nosso domínio, a IA também não entenderá. Ela apenas automatizará a criação de um sistema ruim e acoplado. Podemos usar a IA para ler transcrições de reuniões, extrair o idioma onipresente e ajudar a tomar decisões em nosso core domain. No entanto, a IA nunca substituirá o conhecimento humano. Ela será uma aceleradora, ajudando com o idioma, o código e a construção de padrões, mas não substituirá os domínios e processos.

A IA é a consumidora final que mais exige da nossa indústria, consumindo dados em uma volumetria sem precedentes. Muitos modelos são baseados na internet ou apontam para bases de dados privadas das empresas. Aqui reside um grande perigo: se aplicarmos um modelo poderoso de IA em um data lake caótico, cheio de regras e dados misturados, poderá cruzar tabelas de clientes de suporte com tabelas de clientes de faturamento, misturando conceitos e fornecendo respostas incorretas. A falta de contexto é o que gera as alucinações de IA no ambiente corporativo. Dados incorretos geram resultados incorretos, agora gerados por uma IA.

Subdomínios e Arquitetura

A IA é um motor de escala. Se escalarmos um domínio bem modelado, escalaremos inteligência. Se conectarmos a IA a um sistema desordenado, o domínio escalará com a IA em forma de desordem. A IA será consumidora do nosso domínio e processo. Devemos pensar no sistema que construímos hoje. Nem tudo no sistema tem o mesmo valor estratégico. Se tratarmos cada linha de código com o mesmo peso, podemos desperdiçar dinheiro, energia e tempo da empresa. Para resolver isso, o DDD divide o problema de negócio, o domínio, em partes menores chamadas subdomínios, classificados em três tipos fundamentais: core domain, subdomínios de suporte e subdomínios genéricos.

O core domain é onde vive o coração do software, o diferencial da empresa, o que faz o negócio ganhar mercado e superar a concorrência. Aqui, colocamos nossos melhores desenvolvedores, a melhor arquitetura e gastamos mais esforço. O subdomínio de suporte ajuda o core a funcionar. A empresa pode parar sem ele, mas não é um diferencial competitivo. Altas, registros e CRUDs dão suporte ao nosso domínio principal. Os subdomínios genéricos são problemas comuns que praticamente toda empresa tem, como login, envio de e-mail e gateway de pagamento. A regra é clara: não reinventar a roda. Se o subdomínio é genérico, tentamos trazer uma biblioteca, um software já feito ou um serviço pronto no mercado.

Aplicando na Prática

Pensemos na Netflix. Qual é o grande domínio de dados da Netflix? Streaming de conteúdo e entretenimento. O streaming é um contexto muito grande para um único time desenvolver, então é fragmentado em subdomínios menores, como recomendação, catálogo de conteúdo, faturamento e autenticação. O core domain é onde a magia acontece, como o sistema de recomendação, que sabe exatamente o que vamos assistir no fim de semana para não cancelarmos a assinatura. O subdomínio de suporte pode ser o catálogo de conteúdo, que organiza informações como diretor, sinopse e capa. Sem ele, o motor de recomendação não tem o que sugerir. Os subdomínios genéricos são a burocracia do software, como login e processamento de cartão de crédito, que podem ser integrados com gateways de pagamento globais, como Stripe.

O papel de uma boa arquitetura orientada ao negócio é dizer: compremos algo para esses temas, façamos um CRUD simples como um catálogo e gastemos 60, 70, 80% do nosso tempo e orçamento desenvolvendo o melhor algoritmo de recomendação do mercado. Assim, a arquitetura gera ganho. Conhecer os subdomínios é um conhecimento estratégico, até mesmo executivo, pois permite alocar recursos financeiros a cada parte da aplicação. É extremamente importante que cada empresa identifique seus domínios principais, subdomínios de suporte e subdomínios genéricos na construção do software e da arquitetura.

Importância de Mapear Subdomínios

Por que é tão importante mapear os subdomínios? Porque com essa clareza, podemos evitar problemas clássicos, como decidir se fazemos algo internamente. Quantas vezes participamos de equipes que passaram meses construindo um sistema de login personalizado ou criando um motor de envio de e-mails do zero? Nós, engenheiros e arquitetos, adoramos construir coisas novas, mas estrategicamente, essas coisas não diferenciam o negócio em nada. O cliente não compra nosso produto por ter um sistema de login atraente. O resultado é que, enquanto a equipe gasta energia e orçamento no subdomínio genérico, o core domain, que é o coração da empresa, pode ficar fraco, mal modelado e cheio de dívida técnica.

O principal objetivo é saber onde alocar energia e dinheiro, certamente no core domain, onde a empresa obtém maior faturamento. Merece nossa atenção, é nossa arquitetura de elite. Aqui, passaremos mais tempo, testaremos o melhor design de código, aplicaremos os melhores padrões de design e práticas de clean code, criando uma arquitetura resiliente e escalável, com mais casos e cenários de teste para sermos mais precisos no core domain da aplicação.

Conclusão

Trouxe um gráfico para ilustrar. No eixo vertical está a complexidade do negócio, que indica quão difícil é programar e entender essas regras. No eixo horizontal está a diferenciação no mercado, ou seja, quanto isso faz a empresa se destacar frente à concorrência. Quando tomamos a parte mais alta de complexidade e diferenciação de mercado, podemos identificar nosso core domain. É onde colocamos mais esforço na aplicação e na engenharia. Quanto maior a complexidade do negócio e a diferenciação de mercado, mais fácil é definir as fronteiras entre o subdomínio principal, o subdomínio genérico e o subdomínio de suporte. Nesse quadrante mais alto, engenheiros e arquitetos devem colocar seu melhor talento e prática para a construção da arquitetura.

DDD Tático e Contextos Delimitados - Linguagem Ubíqua e Bounded Contexts

Explicando o conceito de linguagem ubíqua

Agora vamos entrar no conceito mais simples de entender em DDD, mas o mais difícil de aplicar no dia a dia: o linguagem ubíquo, ou como pode ser encontrado em outras literaturas, linguagem onipresente. A regra aqui é simples: todos os envolvidos no ecossistema de um software, de um produto, precisam falar rigorosamente o mesmo idioma. O negócio fala de uma forma, o produto fala da mesma forma, a arquitetura fala da mesma forma e, o mais importante, nosso código também precisa dizer o mesmo.

Quando os projetos começam a dar errado? Quando a mesma palavra passa a ter vários significados, ou pior, quando várias palavras são usadas para a mesma coisa. Imagine em um e-commerce: a equipe de produto diz que precisamos registrar a compra do cliente, então a pessoa desenvolvedora backend cria uma classe chamada ordens, por exemplo; a pessoa DBA cria uma tabela transações; e no final, o serviço financeiro gera um relatório de vendas. Agora imagine quando há um bug em produção: o produto abre um ticket de compra, a pessoa desenvolvedora backend busca logs para a ordem, a base de dados busca logs na tabela de transações, e finanças revisa as vendas. Essa tradução constante que fazemos o tempo todo pode provocar confusões, gerar fricção e, ao final do dia, causar bugs em produção. O tempo de correção desses bugs, devido à tradução constante, pode ser afetado. É exatamente isso que o linguagem ubíquo vem resolver.

Definindo termos comuns e técnicas para linguagem ubíqua

É necessário sentar em uma sala e decidir: qual é o termo que nossa empresa vai usar? Compra? Pedido? Venda? Se concordarmos com o negócio e estabelecermos que a palavra é pedido, a confusão acaba. O produto diz pedido, o relatório financeiro é pedido, a classe em C# é pedido, nosso endpoint também será pedido; ou seja, nosso código se torna um reflexo exato do negócio e, consequentemente, evitamos essas traduções. No linguagem ubíquo, todos falam o mesmo idioma. O negócio fala o mesmo idioma, o produto fala o mesmo idioma, o desenvolvimento fala o mesmo idioma, a arquitetura fala o mesmo idioma sobre seus processos.

Como ajudar a identificar um linguagem ubíquo? Quais são as técnicas que podem ajudar para que todos tenham o mesmo conhecimento e também falem o mesmo idioma? Algumas técnicas incluem conversas com especialistas, várias conversas com especialistas, workshops, como os dias de Storming. Nos workshops, trazemos profissionais especialistas no negócio, assim entendemos melhor os conceitos e definimos essas palavras para que possamos representar esses mesmos termos do nosso domínio na aplicação. Refinamento de backlog e modelagem de domínio são técnicas que nos ajudam a ter um termo único. É conhecer em detalhe um pouco do nosso processo de negócio. E aí vamos trocando experiências também. Virão termos que provêm do processo de negócio e também termos que vêm do nosso modelo de software, termos técnicos.

Crescimento da empresa e desafios de contexto

Até aqui aplicamos o linguagem ubíquo, sentamos com o negócio, definimos os termos e agora nosso código já reflete a realidade do nosso processo. Então o modelo de software finalmente está falando o mesmo idioma para as pessoas. Parece que resolvemos todos os problemas. Agora todos os termos do processo de negócio estão refletindo nossa arquitetura e nosso software. Tudo bem? Até que a empresa cresce. Quando a empresa cresce, quando entramos em uma empresa grande, enfrentamos problemas arquitetônicos também grandes. Às vezes, as palavras têm significados completamente diferentes dependendo da área, dependendo de um andar da empresa. Vamos a um andar, uma palavra tem um significado; em outro departamento, em outro lugar, tem outro significado. E por mais estranho que pareça, para algumas pessoas arquitetas e desenvolvedoras isso é normal. Está bem, ali falamos código de produto e a aplicação o identifica como SKU, tudo bem. Isso pode parecer normal, mas não é. Cada área da empresa pode ver o negócio através de suas próprias lentes. Cada um terá um contexto distinto.

Pensemos na palavra cliente. Vamos ao time de marketing e perguntamos o que é cliente. Eles dirão: cliente é qualquer pessoa que está em nosso sistema CRM, que baixou um manual, um e-book ou se inscreveu em uma newsletter. Depois vamos a outro lugar, a outro departamento, outro andar da empresa. Vamos ao time de vendas e perguntamos o mesmo: fui ao time de marketing, perguntei o que é cliente e me deram essa definição. O que é cliente para vocês? Eles diriam: claro que não. Cliente é apenas quem já assinou o contrato, passou o cartão de crédito, gerou receita. Quem baixou um manual ou e-book é apenas um curioso. De novo, a mesma palavra, duas definições diferentes, totalmente distintas. Ambas corretas em seus mundos, em seus contextos.

Introduzindo contextos delimitados

E qual é o problema da arquitetura tradicional como a nossa? Tentar criar uma tabela única, uma tabela gigante, uma classe cliente com 50 propriedades, tentar juntar atributos que vêm de marketing e de vendas ao mesmo tempo. E então, consequentemente, criar essas classes semideuses, com tudo junto, cheias de ifs e regras conflitantes. Como resolvemos isso? Em DDD, aceitamos que as palavras têm fronteiras e contextos distintos, e aqui é onde entram nossos contextos delimitados, para definir a palavra cliente com um significado diferente em cada caso. Então, para o contexto de vendas, cliente é de uma forma; para o contexto de marketing, o contexto é diferente.

Como podemos resolver esse conflito entre marketing e vendas, sem criar uma classe gigante impossível de manter no código? Aqui o DDD nos entrega o contexto delimitado. Contexto delimitado é, literalmente, uma fronteira linguística e arquitetônica. Serve para definir qual é a forma de representação onde um determinado modelo é válido. Pense nisso como uma cerca invisível. Temos uma cerca, e essa cerca vai definindo nossos contextos. Cada palavra tem um significado único e inquestionável dentro de cada contexto. Ao dar um passo fora, uma palavra em um contexto perde seu significado; ao mudar para outro contexto, a regra muda e a palavra tem um significado distinto.

Aplicando contextos delimitados na prática

Voltando ao exemplo de vendas e marketing, a palavra cliente tem um significado: a pessoa que mostrou interesse; e assim, nossas aplicações, nossos microserviços, nossas bases de dados para marketing estão 100% corretos e representam o cliente para marketing. Quando a pessoa decide fechar uma compra, a informação cruza a fronteira para o contexto de vendas. E no contexto de vendas, o cliente terá outros atributos. Poderá ter um atributo de CPF, contrato assinado, endereço de faturamento.

A grande ideia do DDD (Design Driven Development) é aceitar que ambas as equipes estão rigorosamente corretas, mas a palavra "cliente" está em contextos distintos. Consequentemente, nossa arquitetura também precisa ser diferente para cada contexto. Deixamos de tentar criar um modelo único e genérico para acomodar todos os atributos dentro de uma classe.

Explorando limites invisíveis e mapas de contexto

Vamos falar um pouco sobre os limites invisíveis. Os contextos delimitados têm um impacto muito físico e real em nosso dia a dia. Eles ajudam a definir nossos limites organizacionais e podem auxiliar na divisão de squads, equipes e tribos. Para a arquitetura, cada contexto delimitado deve ter um responsável. Ou seja, uma equipe deve ser responsável por um contexto delimitado. Não há problema, e é possível, que uma equipe tenha um ou mais contextos distintos, dependendo se a equipe é produtiva ou se a empresa é pequena. No entanto, o inverso não é bom. Se colocarmos duas ou três equipes distintas trabalhando no mesmo contexto, podem surgir problemas, como conflitos de merge no repositório, equipes quebrando as regras de negócio umas das outras e falhas no deploy. Essas fronteiras mal definidas do negócio podem gerar problemas.

Como isso se reflete no código? Muitas vezes, confundimos, como arquitetos, que um contexto delimitado é o mesmo que um microserviço, e a resposta é não. Um contexto pode se manifestar de várias formas. Pode ser um sistema completo, um módulo bem isolado dentro de um monólito e, sim, também pode ser um microserviço isolado. O conceito de contexto delimitado é estritamente lógico e semântico. Não é tecnológico e não protege linguagens e regras. O uso de Kubernetes, Kafka, microserviços, C#, no final do dia, são apenas detalhes de implementação. Os limites de microserviço são determinados por equipe ou equipes para justamente mitigar possíveis problemas de fronteira.

Comunicando contextos isolados e criando mapas de contexto

Colocamos muros ao redor de nossos modelos, criando os contextos delimitados. Assim, cada um está seguro com sua própria linguagem e regras. Mas se o sistema é uma ilha isolada que não se comunica com ninguém, se não está bem isolado, como esses contextos isolados se comunicam entre si sem se tornarem um desastre, sem corromper a linguagem do outro? Para responder a essa pergunta, projetamos o mapa de contexto, ou context map. Se o contexto delimitado é o plano detalhado de uma casa, por exemplo, o mapa de contexto é uma visão satelital de todo um bairro. É uma visão de alto nível que mostra quem é vizinho de quem, quais estradas conectam esses vizinhos e, sobretudo, quem depende de quem para sobreviver.

Desenhar um mapa de contexto não é apenas fazer quadrados, setas bonitas, números, PowerPoint; é uma decisão arquitetônica mais séria que deve ser tomada. Quando traçamos uma linha conectando o contexto de vendas com o contexto de logística, por exemplo, estamos definindo o futuro da estabilidade do sistema e da conexão com esse sistema. Estamos pensando em como os microserviços vão se comunicar e se nossas equipes responsáveis por esses contextos terão autonomia ou não. E aqui está a parte mais interessante do contexto, pois nos ajuda a detectar problemas organizacionais; não mostra apenas dependências de código, mas também alguns problemas. Por exemplo, se desenharmos um mapa de contexto e notarmos que o contexto A tem setas de dependências pesadas para B, C, D, o que isso pode significar na prática? Pode significar que a equipe A não pode fazer um deploy em produção sem reuniões de alinhamento com outras equipes e, consequentemente, estão acoplados. Quando vemos isso no mapa, devemos prestar atenção; devemos revisar se nossas fronteiras foram mal definidas ou se a estrutura da empresa está estrangulando a arquitetura.

Exemplificando a criação de mapas de contexto

Trabalhamos em uma empresa onde estamos definindo contextos e mapas de contexto no varejo. Como isso foi feito? Apenas para mostrar um pouco da dinâmica. Trouxemos todos: líderes técnicos, arquitetos, analistas, para dentro de uma sala de vidro grande e começamos a colar post-its nos vidros, tudo o que a equipe de negócios entendia como domínio, o que nós entendíamos como aplicações; colocamos aplicações, microserviços, bancos de dados, tudo na parede, isolado, sem nenhuma ordem. Depois, começamos a agrupar esses post-its por afinidade, como se fossem próximos uns dos outros. Com isso, começamos a delimitar os contextos e a criar os mapas de contextos interconectados. Não foi um trabalho de dias, mas de forma visual começamos a mapear todos os contextos de uma empresa e, consequentemente, as conexões entre eles. Usávamos fio de algodão e conectávamos este contexto com aquele, e de forma visual, naquela época, antes da pandemia, dentro de uma sala, deu uma visibilidade muito boa na criação desse mapa de contexto.

Discutindo o conceito de modelo semântico

Antes de avançar um pouco, vamos falar de um conceito filosófico, que é a verdadeira razão pela qual o DDD existe. Esse conceito se chama modelo semântico. A ideia aqui é que as palavras por si só estão vazias. O significado de uma palavra depende do contexto em que é usada. Falamos um pouco sobre isso anteriormente. Mas tomemos um exemplo bem simples do dia a dia. Certamente já ouviram a velha discussão: o tomate é fruta ou verdura? Se perguntarmos a um botânico, dentro do contexto da biologia, o tomate é, sem dúvida, uma fruta, porque nasce de uma flor e contém a semente. Mas leve esse mesmo tomate para o contexto da culinária. No domínio culinário, é tratado e armazenado como uma verdura. Não colocamos um tomate em uma salada de frutas. É o mesmo objeto físico, mas suas regras e comportamentos podem mudar completamente dependendo de quem o observa. Isso se chama modelo semântico.

Outro exemplo. Pense em um sistema de gestão hospitalar. A palavra "pessoa". Na clínica, no triagem, o domínio semântico "pessoa" é um paciente. Tem sintomas, histórico de doença, tipo sanguíneo. Mas se sairmos da clínica e formos para a área administrativa, como RH, a pessoa já muda sua semântica. Tem outra semântica. Pode significar um médico, enfermeiro ou outro funcionário, com salário, horário, matrícula profissional, dados de RH. Qual é o erro que cometemos? Como mencionado antes, ter classes com 80 campos misturando atributos de clínica e de RH juntos. E então se torna impossível manter. Ter um modelo semântico e sua identificação nos ajuda a definir nosso contexto.

Recapitulando conceitos de DDD

Uma recapitulação geral. Entendemos que nossa arquitetura não começa no banco de dados. Começa entendendo o domínio. Vimos que o domínio gigante precisa ser quebrado em subdomínios: subdomínios principais, subdomínios de suporte, subdomínios genéricos, para nos ajudar a investir tempo e energia em um subdomínio. Descobrimos que precisamos de uma linguagem ubíqua para que todos possam falar o mesmo idioma. Entendemos agora que as palavras têm efeitos de domínios semânticos, ou seja, têm significados diferentes em cada domínio. E, consequentemente, esses diferentes significados em nosso código podem nos ajudar a construir nossos muros como nos Contextos Delimitados. Tudo bem?

Sobre o curso Modelagem de Domínio e Arquitetura Orientada a Negócio

O curso Modelagem de Domínio e Arquitetura Orientada a Negócio possui 167 minutos de vídeos, em um total de 30 atividades. Gostou? Conheça nossos outros cursos de Arquitetura em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Aula 1
• Aula 2
• Aula 3
• Aula 4