Salve, Deus, beleza? Continuamos a saga aqui no Domain Dreaming Design. Agora nós vamos falar sobre um assunto que é muito importante na nossa visão estratégica. A gente está trabalhando ainda com a visão estratégica. Quando nós estabelecemos os subdomínios, temos lá o espaço da solução em relação entre os contextos, nós já vamos meio que saber ou saber qual é o core domain, qual é o ouro ali do nosso software, onde a gente tem que se preocupar e investir mais. Mas esse processo, ele não é escrito em pedra, ele não é definitivo. Quando você vai avançando no design estratégico, vai para o design tático, chega até fazer a implementação no meio do código, você e a sua equipe podem entender que aquilo que foi idealizado ali no design estratégico tem que sofrer modificações. E está tudo bem. Está tudo bem está tudo bem porque isso é algo esperado porque a gente chama de refinamento do domínio que é nós avançarmos cada vez mais ficamos cada vez mais espertos mais experientes naquele problema e nós vamos vendo que elementos precisam ser rearranjados, às vezes subdomínios precisam ser criados, relações precisam ser invertidas para que, de fato, faça sentido a solução daquele problema. Então, se você está começando a trabalhar com o DDD, viu que teve que mudar qualquer coisa, não pode mudar? Pode. Se você viu que tem que mudar, faça essa modificação, porque ela tende a trazer benefícios para a modelagem. Então, tem um assunto lá no livro, esse assunto aqui é tratado no livro do Evans, no Blue Book, que é a destilação de domínio. Então, uma vez que nós temos o espaço aqui da solução, que a gente já identificou ali que tem eventos e ingresso, como os cores domains, então eu quero pegar esse ouro que eu tenho no meu software e declarar a visão desse domínio. A visão do domínio pode até abranger outras áreas também, mas a gente está focado aqui no domínio core. Se a gente fosse definir a visão desse domínio para resolver esse problema de venda de ingressos, o que eu poderia falar? A gente vai desenvolver a aplicação web que vai fazer as compras, vai desplambrizar os ingressos, que vai comunicar lá com os e-mails. Isso não é uma visão de domínio. Essa é uma visão importante, uma visão muito importante, que você vai colocar ela em algum documento, ela vai estar em algum documento, mas a visão de domínio ela não vai considerar aplicação web, mensageria, ou coisas do tipo. Nós queremos entender a essência do negócio. E, obviamente, essa visão do domínio, ela vai acabar sendo uma perspectiva da equipe que está envolvida ali. A visão que a equipe tem no momento. E isso aqui, baseado também no negócio, baseado na modelagem, vai se modificando ao longo do tempo. Então, uma visão do nosso domínio é que esse modelo deve permitir que os clientes comprem ingressos de eventos apenas com cartão de crédito, não sendo possível haver conflitos de lugares. A validação do ingresso no evento deve estar sempre disponível e ser rápida. Parceiros devem conseguir criar eventos e determinar lugares. Quando o cliente fizer o pagamento, este deve ser repartido entre o parceiro e a nossa organização. O modelo deve representar as diferentes visões de usuário. Administradores, parceiros e clientes. O modelo deve permitir a pesquisa dos eventos e compras realizadas pelo cliente e também permitir aos parceiros gerenciar os seus eventos, alterando as informações sobre ele, além de gerenciar os espaços disponíveis. Então, essa aqui seria uma visão do domínio. Nós conseguimos aqui ver os problemas, nós conseguimos extrair até áreas dessa informação, e ela serve como guia para que a gente faça modelagem não procurando a aplicação web. Isso vem depois. É uma decisão, claro, que é essencial que a gente disponibilize essa aplicação na web. Quem duvida disso? Mas aqui a gente não está modelando web, nós estamos modelando o problema, para poder resolver esse problema. Aí eu trouxe aqui um diagrama de classes bem simplificado, hoje a gente poderia chamar isso aqui de mais um DR, Diagrama de Entidade e Relacionamento, mas eu não queria falar entidade, em que nós temos o core domain modelado, que a gente considera que é essencial. E lá no nosso domínio de eventos, pagamento está embutido. Pagamento está aqui. E eu fiz questão de fazer essa separação. Por quê? Porque seria muito ruim a gente só enxergar o evento sem ver que, de de fato o pagamento faz parte daquela situação então aqui nós temos aqueles dois subdomínios mas um deles está fragmentado em duas partes para que a gente veja nesse caso que a compra é o mais importante tá mas o ingresso tem que o ingresso tem que existir, sim. Com certeza. O ingresso precisa existir. Mas o que a gente tem que trabalhar aqui em cima, às vezes a gente vê a compra somente que é o cliente passando o cartão de crédito, mas a gente pode fazer aqui análises em cima das vendas em cima do evento. Se tem assentos disponíveis baseado num determinado tempo. Olha que todo mundo está apontando. Perceberam que todo mundo está apontando para a ordem de compra? A ordem de compra está... Na verdade, vamos fazer a... Está aparecendo uma seta para baixo, mas ele está apontando para todo mundo, ou seja, ele está usando as informações do nosso core domain para poder fazer as coisas acontecerem. Aqui a gente tem o parceiro. Um parceiro pode ter zero ou vários eventos. Um evento pode ter um ou vários assentos. Normalmente, um evento vai ter muito mais que um. E a ordem de compra tem um assento. Eu posso ter um evento e zero compras. Então, um para zero ou várias. Toda ordem de compra também tem um cliente e vai ter ali a relação com o ingresso que foi vendido. Então, isso aqui seria uma visão um pouco mais, um zoom, mais um do nosso core. E por que eu estou querendo mostrar isso aqui relativo também com a relação com a declaração da visão de domínio? Porque quando a gente olha para a declaração de visão de domínio, nós queremos ainda fazer uma imersão nela para encontrar o que o Evans chama de núcleo segregado. Porque mesmo ainda ali naquele core domain, eu posso ver qual é a essência, qual é a alma ainda desse coração que o meu core domain é o ouro, mas eu entro e eu tenho diamante lá dentro então esse diamante ainda, essa visão que a gente sabe que ali nós temos que errar menos ou errar rápido e saber consertar aquilo ali vai ter um grande investimento é ali que eu vou colocar os melhores desenvolvedores da minha empresa, ali que eu vou ter que fazer o refinamento mais cuidadoso porque se isso aqui não funcionar o meu software não vai se pagar então tem um capítulo também no livro que se chama na verdade não é um capítulo, é uma parte do livro do Evans que se chama Camadas de Responsabilidade, que se você quiser encontrar está próximo da Declaração de Domínio. Isso aqui, na verdade, é um conceito de arquitetura do Bushman, do livro do Bushman. Não lembro agora de cabeça, mas é um livro de arquitetura do Bushman, do livro do Bushman. Não lembro agora de cabeça, mas é um livro de arquitetura do Bushman. E ele quer pegar as áreas do software e fazer uma separação para entender... Olha só que legal isso. Para entender as responsabilidades de cada camada que a gente tem. Aqui a gente não está olhando o subdomínio, a gente está olhando os agentes dentro do subdomínio, as entidades. Daqui a pouco a gente vai falar sobre isso. Mas o Evans acaba pegando essas divisões de responsabilidade e até adicionando mais camadas de responsabilidade. Então, nós temos potencial, operações e política. A ideia, inclusive, é que a gente tem aqui... Deixa eu pegar uma setinha que vai para baixo. é que a gente tem aqui, deixa eu pegar uma setinha que vai para baixo. Quando a gente determina essas responsabilidades, nós temos uma dependência entre essas camadas que vai fluir de cima para baixo. Ou seja, nessa visão que a gente está olhando aqui de decisão para baixo. Então, se eu virar aqui, para que não fique ruim para vocês poderem ver, nós temos esse cenário aqui. Uma camada que está abaixo não depende de uma camada que está acima. Abaixo não depende de uma camada que está acima. Uma camada que está acima pode depender das camadas que estão embaixo. Lá embaixo nós temos o potencial, que a gente pode chamar também de capacidade. Qual que é o estado atual dos recursos que eu tenho dentro do meu negócio. E esses recursos são justamente os clientes, os assentos, os event spots, o evento, e parceiro, eu não coloquei aqui a relação, por isso que eu fiz o diagrama de classe simplificada, eu não coloquei aqui as notações de 1 para N, N para M e etc. Para poder ficar mais simples. Então, esse aqui é o potencial da minha empresa. Já as operações vão ser a parte dos ingressos, porque eu tenho que gerar esses ingressos, tenho também que fazer a validação do uso desses ingressos, apesar de você pensar em entidades e classes. Espera aí, como assim o uso do ingresso vai ser uma entidade? Eu posso criar, registrar ali a validação do ingresso que aconteceu. Isso aqui faz com que a gente continue... A nossa empresa tem que trabalhar para isso aqui acontecer. Não adianta nada a gente fazer a venda do ingresso sem que a validação, o uso do ingresso aconteça. Então, isso aqui é a operação do meu negócio. Já em parte de política, como o nosso exemplo é muito simples, são estratégias para a gente conseguir continuar melhorando esse negócio, baseado nas ações que eu tenho. Então, nós poderíamos ter políticas de desconto, cupons de desconto, ou até políticas de conflito de compra. Vai que você está comprando, a gente não pode comprar ingressos repetidos, mas uma vez que você tentou comprar ali um ingresso, outra pessoa já comprou o primeiro, nós poderíamos ter uma política de cupom, a gente vai te ofertar aqui um outro show depois, alguma coisa nesse sentido. São estratégias que nós vamos fazer para poder trabalhar com o potencial e com as operações. Na parte de decisão, é onde nós vamos ter o apoio, a tomada de decisões. E tudo parte das vendas. Está vendo que vendas está utilizando as camadas mais abaixo? E as camadas mais abaixo não dependem de vendas? Tudo parte das vendas. Pode ficar um pouco abstrato, mas vamos lá. Eu estou recebendo muitos acessos. Então, vou ter que tomar uma tomada de decisão aqui, que eu preciso suportar aqueles acessos para poder fazer as minhas vendas. suportar aqueles acessos para poder fazer as minhas vendas. A gente não vai jogar nada para um sistema de mensagens para poder fazer o pagamento depois. O pagamento tem que acontecer agora. Então, vou ter que escalar essa parte aqui. Isso aqui vai ter que funcionar muito bem. Cliente, assento, evento, isso aqui não precisa ter grande escalabilidade, não. Os parceiros não vão ficar criando eventos o tempo inteiro. A gente não vai ter um uso extensivo comparado à compra. E também eu posso mudar o preço do ingresso baseado ali em várias estratégias que a gente usaria da política. Então compra depende, a minha decisão, a minha decisão de venda, ela depende dessas outras camadas aqui. Então a gente vai aprofundando e vê que o que você tem em decisão está num ponto essencial do seu sistema. É o diamante. Isso aqui tem que funcionar muito bem. Claro que eu tenho potencial. O potencial aqui define o quanto que eu estou faturando com esse sistema. Porque se o meu potencial estiver baixo, eu não vou conseguir vender. Mas se o meu potencial estiver baixo, eu não vou conseguir vender. Mas se o meu potencial estiver baixo, isso muda como eu vou trabalhar com as vendas e também muda aqui a minha política. Nesse caso, eu estou encaixando aqui política, mas às vezes pode ser uma entidade em si. No uso do ingresso, se a gente for pensar um pouco melhor, ele não estaria também ligado aqui à decisão? Então, eu teria que apontar isso aqui para baixo. Porque eu tenho um pouco mais de espaço. Então, eu posso falar que, na verdade, o uso aqui do ingresso ele envolve decisões ele envolve uma tomada de decisão no meu negócio porque imagina que eu tenho 100 eventos marcados para a mesma hora. Então, aquilo ali vai envolver uma resposta diferente do meu software. E ele está apontando para baixo, ou seja, ele acaba dependendo aqui da parte de ingresso. Veja que nenhuma das áreas de baixo depende das de cima. Por isso que a dependência é para baixo. Isso aqui faz com que a gente saiba que mudanças na tomada de decisão, você vai perder uma grana se você fizer alguma coisa de errado. Se você fizer alguma mudança no evento em si, o parceiro pode não representar, não tem um grande risco quando comparado com a parte de decisão. Então, esse capítulo de responsabilidade, essa camada de responsabilidades e a declaração da visão do domínio faz com que a gente vá refinando esse conhecimento, entendendo mais o problema, entendendo aonde estão as criaticidades. E veja, a gente nem chegaria no System Design. Depois a gente chegaria no System Design e com essas informações eu consigo criar um System Design ainda melhor, porque eu já sei aonde estão os problemas aonde estão as camadas mais críticas isso vai me apoiar muito mais a ter essa visão agora de como que a gente vai desenhar o sistema funcionando, as comunicações e etc. Show de bola pessoal então vamos continuar nossa saga, é isso aí e até a próxima