Salve, Deus, beleza? Continuamos essa saga aqui no Domain Dreaming Design. Agora vamos falar sobre a linguagem Ubiqua. O Vernon falou disso principalmente nas primeiras aulas. E isso é muito bem falado tanto no Red Book quanto no Blue Book, nos dois livros aí do Evans e do Vernon. E, na minha opinião, eu vejo que esse assunto aqui é muito subestimado, porque sempre vamos voltar àquela situação. A gente encara o DDD como mais valioso na parte tática. E DDD é comunicação, é todo mundo falar a mesma linguagem, é identificar os problemas, a tática é depois da estratégia. Então, a gente tende, inclusive o Evans fala isso aqui, a gente tende a negligenciar essa linguagem, o bico aqui. Cada contexto que nós temos dentro dos nossos subdomínios tem a sua própria língua, porque nós vamos ter o relacionamento com os domain experts dessas áreas. E a gente precisa respeitar esse idioma, essa linguagem que é extraída. Então, valorize muito os termos, às vezes as metáforas, ou algum trocadilho, alguma coisa. Isso é muito importante porque a comunicação vai fluir mais e a gente vai conseguir captar a essência do problema. A gente pode achar que linguagem ubíqua, que a primeira coisa que viria na nossa cabeça, que seria a UML que está aqui. Que é a linguagem de modelagem unificada. Poxa, está o nome aí. Mas a linguagem ubíqua não é só a UML. A UML é ótimo porque são documentos, uma série de diagramas que podem ser gerados que são entendíveis por pessoas que não são técnicas, pessoas que são leigas. Mesmo que eu mostrar um diagrama de classe, mesmo que tenha algumas coisinhas lá, as pessoas vão conseguir entender, de certa maneira, o que está acontecendo. Casos de uso já são mais próximos de pessoas que são leigas, enfim. Então, a UML é ótima, mas a gente não precisa usar necessariamente a UML. Eu vejo que começar por um dicionário de termos, para que todo mundo que, às vezes a gente tem equipes, pessoas que estão entrando, pessoas que estão saindo, é necessário estabelecer ali os termos que nós vamos conversar e o que esse termo significa dentro daquele contexto. Porque às vezes eu mudo de contexto, aquele termo pode ter um significado diferente ou às vezes bem diferente em relação ao outro contexto. Então a gente tem a definição de ingresso, de evento, de assento, de cliente, de ordem de compra, de parceiro. Então o ingresso se refere ao assento comprado pelo cliente. Agora, veja que o ingresso em si pode ser considerado... Isso que me veio na cabeça aqui agora. Eu coloquei esse se refere ao assento comprado pelo cliente, mas o ingresso em si pode ser apenas aquele documento que é gerado ali referente ao assento comprado. Então, talvez, para ser mais claro aqui, seria se refere ao documento que valida a compra do assento pelo cliente. Porque às vezes a gente pode estar falando do ingresso se referindo ao assento. E essas discrepâncias, esses ruídos de comunicação, eles podem fazer, acredite, tá? Isso é muito sério. Isso pode fazer com que você erre totalmente o entendimento do problema e essa modelagem errada depois vai gerar um software lá na frente que a gente vai ter que reconstruir ou fazer as modificações. E isso é muito mais caro. Isso vai fazer a empresa perder valor. Então a gente coloca todos os termos do evento, se refere ao acontecimento com data, hora e lugar. O assento se refere ao espaço que será vendido ao cliente, aquele espaço disponível. O cliente é o próprio consumidor dos assentos, que compra os assentos. A ordem de compra é a compra realizada pelo cliente com os seus devidos dados. E o parceiro é a organização ou uma pessoa que organiza um evento ou o evento em si. Beleza, esse dicionário de termos aqui, ele vai fazer com que todo mundo ali saiba que ele tem que, quando eu vou me referir, às vezes eu quero usar uma palavra ticket, eu quero usar a palavra em inglês, a gente vai deixar de usar a palavra em inglês justamente porque isso pode levar as outras pessoas a entenderem outras coisas. contexto, com aqueles significados e aí se você está saindo desse subdomínio, às vezes um outro subdomínio pode ter que se referir ao ingresso, mas lá, às vezes, pode ser que um outro termo seja mais adequado. Vou dar um exemplo de um outro tipo de aplicação, porque essa aqui é muito simples. Imagina que eu tenho um sistema hospitalar e lá na área médica os médicos não vão se referir à pessoa como um cliente. Seria estranho. O médico vai falar paciente. Então na hora que eu for conversar com o médico, na hora que eu for modelar e extrair os requisitos ali, eu vou falar paciente, não vou falar cliente, porque cliente pode levar ele a pensar algumas outras coisas e te falar algumas informações que não são exatamente as que você precisava para poder fazer a sua modelagem. Enquanto lá no financeiro, ou numa outra parte do hospital ali, talvez falar paciente pode ser aplicável, porque paciente é a palavra mais genérica, mas se a gente falasse lá, então, talvez cliente, o cliente aqui do hospital. Então, vamos usar cliente lá nesse contexto. Então, nós temos que entender que os subdomínios é como se fossem várias tribos. E nós temos essa linguagem propriamente dita, e isso aqui, essa língua, ela acaba indo... Quando você vai usar a modelagem tática, você extrai essa língua e transcreve ela com a modelagem tática, com o design tático. Mas, de uma forma geral, use um dicionário de termos, anote metáforas, outras expressões que os domain experts principalmente utilizam. Mas qualquer outro tipo de documento que seja útil ali para que todo mundo fale a mesma língua, você pode usar. Pode usar papel de pão, pode usar um documento de System Design, pode usar algum documento que você viu lá no módulo do Cassio e Botaro, não tem problema. Nem o Evans, nem o Vernon, nem outros autores, eles delimitam que você tenha que usar algum tipo de documento. Inclusive, nos livros, eles vão acabar muito usando aqueles diagramas, meio diagrama de classes da UML, mas bem simplificado, que a gente não tem ali os atributos, não tem nem a chave primária, não tem as operações, só tem o nome da classe. E aí tem o relacionamento, vai apontando as setinhas e etc. Isso é muito legal. O visual também ajuda a comunicar. Então, está na nossa soft skill de identificar qual comunicação, quais métodos de comunicação seriam adequados. Muitas vezes, a gente vai descobrindo esses métodos conforme a gente vai conversando ali naquele contexto específico. Ah, vou lá para o subdomínio conversar com aqueles domain experts. Talvez aquela comunicação, talvez aqueles modos de conversar que eu estava usando no outro contexto, eles não cabem no outro. Então, você precisa saber com quais pessoas você está se comunicando, como você vai abordar os termos. Show de bola, pessoal. Então, vamos seguir na nossa saga. É isso aí. E até a próxima.