DEV Community: José Roberto Araújo

Vertical Slice: Um Déjà Vu do CQRS

José Roberto Araújo — Wed, 29 May 2024 14:30:26 +0000

No cenário em constante evolução da arquitetura de software, certos padrões emergem para enfrentar desafios específicos na construção de aplicações sustentáveis, escaláveis e eficientes. Dois desses padrões são Command Query Responsibility Segregation (CQRS) e Vertical Slice Architecture. Embora o CQRS tenha sido uma abordagem de design proeminente por vários anos, a Vertical Slice Architecture, popularizada por Jimmy Bogard, ganhou força por sua metodologia pragmática e focada em capacidades de negócio e funcionalidades de negócio.

Este post traça um paralelo entre a história e as motivações por trás do CQRS, explora o conceito de arquitetura Vertical Slice e compara esses dois padrões usando exemplos de código C# e organização de soluções do Visual Studio.

A origem e motivações por trás do CQRS

O Surgimento do CQRS

Fundamentado no CQS, criado por Bertrand Meyer, Command Query Responsibility Segregation (CQRS) é um padrão arquitetural introduzido por Greg Young por volta de 2010. O CQRS foi concebido para resolver vários problemas inerentes às arquiteturas tradicionalmente monolíticas e em camadas, onde as várias operações estavam implementadas em uma única base de código e muitas vezes uma única classe continha várias operações de leitura e escrita aninhadas, fornecendo vários tipos de operações sem separação de responsabilidades.

As arquiteturas tradicionais geralmente combinam operações de leitura e gravação na mesma base de código e modelos de dados, levando a uma lógica que, muitas vezes, pode se tornar complexa de manter e também muito acoplada, tornando difícil a manutenção e evolução do sistema.

Problemas resolvidos pelo CQRS

Separação de preocupações: Ao segregar comandos (escrita) de consultas (leituras), o CQRS promove uma separação clara de responsabilidades. Essa separação permite que os desenvolvedores otimizem e dimensionem as operações de leitura e gravação de forma independente, resultando em um código mais eficiente e de fácil manutenção.
Otimização de desempenho: Em muitas aplicações, as operações de leitura giram em torno de 95% das tarefas executadas por um sistema, e apenas 5% do restante das operações são de gravação. O CQRS permite otimizar modelos de leitura separadamente dos modelos de gravação, muitas vezes levando a ganhos significativos de desempenho.
Escalabilidade: Com o CQRS, diferentes partes do sistema podem ser dimensionadas de forma independente. Por exemplo, um aplicativo com muita leitura pode expandir seus componentes de leitura sem afetar o lado de gravação.
Gerenciamento de complexidade: o CQRS facilita o gerenciamento de validações e lógicas de negócios complexas no lado da gravação, mantendo o lado da leitura simples e otimizado para consultas.

⚠️ Não é uma regra ter que separar as instâncias de sua aplicação em uma instância de leitura e uma outra de escrita (gravação). essa abordagem pode acontecer, mas apenas em casos em que a performance do sistema demande essa separação física dos componentes. Aplicar CQRS em sua essência e em seu último nível de implementação arquitetural, vai introduzir um alto grau de complexidade para dentro da solução da sua arquitetura. Por isso, não seja purista aplicando 100% do que você leu e aprendeu sobre esse padrão arquitetural, analise e pense qual é o nível de abstração e implementação que o seu sistema demanda do padrão CQRS!

Sistemas CRUD-Based ofuscam a modelagem de um sistema

Existem muitos sistemas que ainda estão sendo construídos com base no fundamento de servir aos clientes (eg.: Frontend), apenas o DTO que é usado no lado servidor, afim de simplificar o processo de desenvolvimento, buscando acelerar a entrega de funcionalidades no mercado.

Esse tipo de abordagem, conduz não só os desenvolvedores do sistema, mas também implica, negativamente, no desenho das telas, levando a uma UI/UX a terem funcionamento atômico, onde o comportamento das funcionalidades se resumem à apenas uma ação que estimule um sistema a recolher todas as alterações feitas na tela (UI/UX), envie para o servidor o DTO alterado, implicando, no final do processamento, persistir esses dados alterados em alguma base de dados.

Através dessa abordagem, muitos pontos de design - não apenas de UI/UX, como também de software e modelagem de negócio, ficaram perdidos ao longo de todo o processo de desenvolvimento, testes e definição de negócio. Uma importante definição de negócio, a qual deveria levar em consideração: as intenções, nesse modelo de desenvolvimento são facilmente deixadas de lado. Se fossem melhor melhor exploradas, poderiam resultar delimitação do escopo das ações em um formato mais bem definido, tornando, inclusive, mais fácil a implementação de sistemas ou parte de sistemas que se baseiam em CRUD.

Abaixo tem uma tela de um perfil de usuário, como exemplo:

Através dessa imagem, é fácil notar que a intenção dessa tela é gerir, de uma maneira geral, o perfil de um usuário. Tornando difícil de descobrir qual foi a real intenção que um usuário teve, ao clicar no botão salvar. Isso porque o frontend vai capturar todos os dados que existirem na tela e vai enviar, de volta para o servidor. Com isso o rastreamento da operação fica ofuscado pela modelagem CRUD-Based.

Interface de usuário baseada em tarefas

A ideia básica por trás de uma UI baseada em tarefas ou indutiva, é descobrir como os usuários desejam usar o software e fazer com que ele os oriente nesses processos. O objetivo é orientar o usuário durante o processo.

Um software desenhado com base em uma interface baseada em tarefas adotaria uma abordagem diferente, provavelmente separaria as ações de gestão de dados pessoais, endereço e dados de cobrança em seções diferentes, onde cada uma delas pudessem demonstrar a intenção sobre a ação desejada. A intenção do usuário é clara neste caso e o software está guiando os seus passos através do processo de gestão de cada parte da informação de forma isolada, porém contextualizada dentro do perfil do usuário. Dessa forma, as ações podem ser usadas para a criação de comandos que representam as intenções do usuário com este estilo de interface.

A tela acima contém uma ação para gestão de dados pessoais!

A tela acima contém uma ação para gestão de dados de cobrança!

Capacidades de negócio + Funcionalidades de negócio:

💡 Todo sistema é construído com base em uma necessidade de negócio, a qual demanda que esse produto seja orientado às capacidades de negócio destinadas a resolver um problema específico de um dado plano de negócio, em um dado nicho de mercado, e também aborda quais serão as funcionalidades de negócio definidas para cada uma dessas capacidades.

Um sistema de Consultas Veterinárias, pode ter como capacidades de negócio:

Agendamento de consulta
Histórico médico
Acompanhamento de tratamentos
Cobrança

E cada uma dessas capacidades pode conter diversas funcionalidades, como por exemplo:

Histórico médico
- Revisar o histórico do paciente
- Atualizar o histórico do paciente
Agendamento de consulta
- Procurar veterinário disponível
- Agendar consulta

Implementação básica de CQRS

Vamos voltar um pouco ao contexto do exemplo das imagens acima. Em uma implementação típica de CQRS, comandos são usados para realizar operações de gravação e consultas são usadas para recuperar dados que representam o estado atual de uma parte do sistema. Aqui está um exemplo simples em C#:

Exemplo de um Comando (Command):



public class AtualizarDadosPessoaisCommand
{
    public int ClienteId { get; set; }
    public string Nome { get; set; }
    public DateTime DataNascimento { get; set; }
}

public class AtualizarDadosPessoaisCommandHandler
{
    private readonly IClienteRepositorio _clienteRepositorio;

    public AtualizarDadosPessoaisCommandHandler(IClienteRepositorio clienteRepositorio)
    {
        _clienteRepositorio = clienteRepositorio;
    }

    public void Handle(AtualizarDadosPessoaisCommand command)
    {
        var dadosPessoais = new ClienteDadosPessoais
        {
            ClienteId = command.ClienteId,
            Nome = command.Nome,
            DataNascimento = command.DataNascimento
        };

        _clienteRepositorio.AtualizarDadosPessoais(dadosPessoais);
    }
}

Exemplo de uma Consulta (Query):



public class ObterClientePorIdQuery
{
    public int ClienteId { get; set; }
}

public class ObterClientePorIdQueryHandler
{
    private readonly IClienteRepositorio _clienteRepositorio;

    public ObterClientePorIdQueryHandler(IClienteRepositorio clienteRepositorio)
    {
        _clienteRepositorio = clienteRepositorio;
    }

    public Cliente Handle(ObterClientePorIdQuery query)
    {
        return _clienteRepositorio.ObterPorId(query.ClienteId);
    }
}

Uma solução arquitetural que adota os conceitos CQRS, normalmente carrega como base de definição uma organização de projeto seguindo capacidades de negócio, detalhando as funcionalidades intrínssicas dentro de cada uma dessas capacidades. Abaixo, deixo um exemplo de organização de solução onde está explicitamente citada a capacidade de gestão de perfil de cliente (usuário) e quais são as funcionalidades que compõe essa capacidade. Essa abordagem permite que um projeto de software seja fácil de ser compreendido tanto do ponto de vista sobre QUE PROBLEMA ele está resolvendo e COMO está organizada a base de código dessa solução, além, também, de facilitar a compreensão sobre que tipo de padrão está sendo adotado em sua implementação.



.sln (solution)

├── Capacidades-de-negocio

│   ├── PerfilCliente

│   │   ├── AtualizarDadosPessoais

│   │   │   ├── AtualizarDadosPessoaisCommand.cs

│   │   │   ├── AtualizarDadosPessoaisCommandHandler.cs

│   │   │   └── AtualizarDadosPessoaisResponse.cs

│   │   ├── AtualizarDadosCobranca

│   │   │   ├── AtualizarDadosCobrancaCommand.cs

│   │   │   ├── AtualizarDadosCobrancaCommandHandler.cs

│   │   │   └── AtualizarDadosCobrancaResponse.cs

│   │   ├── ObterClientePorId

│   │   │   ├── ObterClientePorIdQuery.cs

│   │   │   ├── ObterClientePorIdQueryHandler.cs

│   │   │   └── ObterClientePorIdResponse.cs

│   ├── ...

Introdução à arquitetura Vertical Slice

O que é esse tipo de arquitetura?

A Arquitetura Vertical Slice, defendida por Jimmy Bogard, é um padrão que estrutura o código por capacidades de negócio e suas funcionalidades intrínssicas e não com base em CRUD-based. Essa abordagem promove o encapsulamento de todos os aspectos de um recurso (UI, lógica de negócios e acesso a dados) em uma única fatia vertical. Cada slice (fatia) é independente, tornando o sistema mais modular e mais fácil de manter.

Principais vantagens da arquitetura Vertical Slice

Foco em capacidades e funcionalidades de negócio: a organização do código é definida pelas capacidades e funcionalidades de negócio, alinhada à forma como os usuários finais percebem o aplicativo, tornando-o mais intuitivo para os desenvolvedores trabalharem em funcionalidades específicas.
Isolamento e Modularidade: Cada slice (fatia) é isolada umas das outras, reduzindo o risco de efeitos colaterais não intencionais ao modificar um recurso.
Maior capacidade de manutenção: Unidades de código menores e independentes são mais fáceis de entender, testar e refatorar.
Desenvolvimento Paralelo: As equipes podem trabalhar em diferentes fatias simultaneamente, sem atrapalhar umas às outras, acelerando o desenvolvimento.

Implementação do Vertical Slice

Na arquitetura Vertical Slice, cada recurso inclui tudo o que precisa para funcionar: comandos, consultas, manipuladores e, às vezes, até mesmo a camada de acesso ao banco de dados. A partir desse ponto, começamos a ter um Dèjá Vu sobre a perspectiva com a qual o Vertical Slice orienta a organização da solução, nos levando de volta à como o CQRS também organiza uma solução de projeto de software, baseando-se em capacidades e funcionalidades de negócio.

Reaproveitando o mesmo contexto de negócio que foi utilizado para exemplificar o CQRS, veja como você pode organizar uma solução em seu projeto de software, usando Vertical Slice:



.sln (solution)

├── Capacidades-de-negocio

│   ├── PerfilCliente

│   │   ├── AtualizarDadosPessoais

│   │   │   ├── AtualizarDadosPessoaisCommand.cs

│   │   │   ├── AtualizarDadosPessoaisCommandHandler.cs

│   │   │   └── AtualizarDadosPessoaisResponse.cs

│   │   ├── AtualizarDadosCobranca

│   │   │   ├── AtualizarDadosCobrancaCommand.cs

│   │   │   ├── AtualizarDadosCobrancaCommandHandler.cs

│   │   │   └── AtualizarDadosCobrancaResponse.cs

│   │   ├── ObterClientePorId

│   │   │   ├── ObterClientePorIdQuery.cs

│   │   │   ├── ObterClientePorIdQueryHandler.cs

│   │   │   └── ObterClientePorIdResponse.cs

│   ├── ...

Comparação: CQRS vs. Vertical Slice

Semelhanças

Separação de capacidades e funcionalidades de negócio: Tanto o CQRS quanto o Vertical Slice enfatizam a separação por capacidades e funcionalidades de negócio dentro de uma solução, resultando em um código mais limpo e de fácil manutenção.
Modularidade: Cada abordagem promove a modularidade, facilitando o dimensionamento e a modificação de partes do sistema de forma independente.
Foco em tarefas: A arquitetura Vertical Slice, assim como o CQRS, é orientada pela implementação específica de tarefas, garantindo que o código seja organizado em torno das funcionalidades de negócios.

Diferença

Gerenciamento de Complexidade: Dependendo do grau de demanda de escalabilidade de um sistema, o que pode levar a implementação do último nível do CQRS, pode introduzir complexidade adicional devido à abordagem de separação das instâncias de escrita e leitura, implicando em uma solução que precisaria lidar com consistência eventual. O Vertical Slice visa reduzir a complexidade, mantendo o código relacionado junto na mesma fatia.

Conclusão

Tanto o CQRS quanto a arquitetura Vertical Slice oferecem paradigmas valiosos para estruturar aplicações modernas. O CQRS é excelente em cenários onde as operações de leitura e gravação precisam ser otimizadas de forma independente e podem lidar com lógica de negócios complexa de forma eficaz. A Arquitetura Vertical Slice, por outro lado, fornece uma abordagem mais intuitiva e de fácil manutenção, organizando o código em torno de recursos, facilitando o desenvolvimento e o gerenciamento.

Ao compreender os pontos fortes e as nuances de cada padrão, os desenvolvedores podem escolher a arquitetura mais apropriada para suas necessidades específicas, resultando em aplicativos mais robustos e de fácil manutenção. Quer você opte pela separação estrita de preocupações oferecida pelo CQRS ou pela modularidade focada em recursos do Vertical Slice, ambos os padrões fornecem ferramentas poderosas para o desenvolvimento de software moderno.

Referências

Scalar: Documentação OpenAPI Moderna

José Roberto Araújo — Fri, 24 May 2024 14:34:35 +0000

Swagger é uma das ferramentas mais utilizadas para documentação de APIs, mas seu tempo pode estar chegando ao fim com a chegada do Scalar UI.

Contexto histórico do Swagger

A história de uso do Swagger como ferramenta para documentação OpenAPI começa com a sua criação em 2010 por Tony Tam, enquanto trabalhava na empresa Reverb Technologies. Desde o início, seu objetivo era simplificar o processo de documentação de APIs para desenvolvedores.

Com o Swagger, era possível criar uma interface amigável para APIs RESTful, permitindo aos desenvolvedores entender o funcionamento de uma API sem precisar mexer no código fonte. Além disso, o Swagger também permite testar a API diretamente no navegador, o que economiza tempo e esforço dos desenvolvedores.

Em 2015, a Swagger foi doada para a Linux Foundation e se tornou parte do projeto OpenAPI. Juntamente com outras ferramentas, o Swagger ajudou a definir o padrão OpenAPI para documentação de APIs. Resultando na UI que já estamos acostumados a trabalhar por anos:

Apesar de sua popularidade e amplo uso, a UI do Swagger também tem suas limitações. Por exemplo, durante todo esse tempo a UX do Swagger permaneceu praticamente a mesma, além de não permitir uma documentação que contivesse textos explicativos sobre os endpoints da API.

Scalar como alternativa na documentação OpenAPI

O Scalar é uma ferramenta que vem servir como alternativa para documentação de APIs usando a especificação OpenAPI. Lançado recentemente, o Scalar se destaca por sua interface de usuário moderna e intuitiva, permitindo criar documentações contendo textos declarativos e explicativos sobre o negócio, funcionalidades, payloads e muitas outras formas de documentar uma API.

A interface do Scalar é limpa e simplificada, tornando-a mais acessível para qualquer pessoa que tenha interesse ou precise entender quais funcionalidades estão disponíveis em uma API. Além disso, o Scalar é mais rápido que o Swagger para documentar APIs complexas, graças ao seu eficiente mecanismo de renderização, além de disponibilizar opções de exemplos de uso das APIs em diversas linguagens e plataformas, o que traz bastante facilidade para quem está querendo usar uma API.

A integração do Scalar com a especificação OpenAPI significa que é possível importar e exportar documentação de API no formato OpenAPI, seja no formato json ou no formato yaml. Isso facilita a transição de outras ferramentas para o Scalar.

O Scalar também oferece integração com várias outras plataformas:

.NET
GO
Rust
NestJS
Dentre outras que pode ser encontradas no repositório oficial do projeto

Durante esse artigo, vamos demonstrar o uso do Scalar em um projeto AspNet Core usando .NET 8.0.

Habilitando Scalar UI em um projeto AspNet Core 🚀

Para demonstrar o uso do Scalar em um projeto .NET, vamos considerar um projeto AspNet Core simples usando .NET 8.0, e que vai conter uma API para um sistema de gestão de hotéis.

⚠️ Se você está rodando seus projetos já usando o .NET 9.0, a versão do Scalar a ser usada será um outro pacote com um nome diferente do apresentado neste artigo, disponível no Nuget.

A versão que pode ser usada com o .NET 8.0 pode ser ou a 1.0.0 ou a 1.0.1-rc

Primeiro, precisamos adicionar o pacote Scalar ao nosso projeto através do NuGet:

dotnet add package AspNetCore.Scalar --version 1.0.1-rc

Em seguida, podemos configurar o Scalar em nosso arquivo Program.cs:

...

var app = builder.Build();

app.UseScalar(options =>
            {
                options.UseTheme(Theme.Default);
                options.RoutePrefix = "api-docs";
            });
...

No trecho de código acima, estamos configurando o Scalar para servir nossa documentação de API na rota "/api-docs".

💡 Para usar o Scalar você não precisa desinstalar o Swagger do seu projeto, pois ambos conseguem conviver lado a lado. Se você já tem o swagger instalado no seu projeto, basta instalar o pacote do Scalar e adicionar o código acima e o pacote vai saber localizar a Url Path do swagger contendo a documentação da API no formato OpenAPI.

Finalmente, podemos acessar nossa documentação de API navegando para "http://localhost:[PORTA_DEFINIDA]/scalar-api-docs" em um navegador de sua preferência. A partir daí, podemos interagir com nossa API diretamente da interface do Scalar.

Esse exemplo ilustra um pouco do que o Scalar pode trazer de melhorias para a documentação da API do seu projeto. Com sua interface moderna e recursos poderosos, o Scalar é uma excelente alternativa ao Swagger para documentação OpenAPI.

A imagem abaixo mostra o resultado da integração do Scalar em uma aplicação AspNet Core:

Perceba que a UI oferece uma experiência de usabilidade bastante diferente do que se está acostumado a ver com o Swagger. Além da UX diferente, também é possível realizar navegação pelas APIs e escolher uma plataforma para que o Scalar possa gerar um exemplo de código que se ajuste a sua necessidade, através das Client Libraries.

Scalar, .NET 9.0 e OpenAPI

O time do AspNet Core está trabalhando na implementação de um pacote oficial da Microsoft, o qual vai trabalhar entregando 100% das especificações OpenAPI. Nesse sentido, o pacote Swashbuckle será removido ❌ a partir do .NET 9.0, passando somente a ser possível utilizar o novo pacote: Microsoft.AspNetCore.OpenApi.

O pacote Scalar.AspNetCore, a partir da versão 1.0.1, será possível se integrar com as novidades que virão junto com o .NET 9.0 e a nova API de documentação, que trás um nome bastante óbvio: Microsoft.AspNetCore.OpenApi.

Validando sua especificação usando: Spectral

Spectral é um linter de documentos OpenAPI de código aberto. O pacote Spectral pode ser incorporado à construção de seu aplicativo para verificar a qualidade dos documentos OpenAPI gerados. Para instalar o Spectral siga as instruções através do repositório oficial.

Para tirar vantagens do Spectral você precisa realizar algumas configurações e instalar um pacote no seu projeto, antes de utilizar a ferramenta de Linter. Instale o pacote Microsoft.Extensions.ApiDescription.Server, ele vai permitir que seja gerada a documentação OpenAPI no momento do build do projeto.

dotnet add package Microsoft.Extensions.ApiDescription.Server --prerelease

Configure o seu projeto para gerar documentos no momento da compilação definindo as seguintes propriedades no arquivo .csproj do seu aplicativo:

<PropertyGroup>
    <OpenApiDocumentsDirectory>$(MSBuildProjectDirectory)</OpenApiDocumentsDirectory>
    <OpenApiGenerateDocuments>true</OpenApiGenerateDocuments>
</PropertyGroup>

Execute o build do seu projeto para que seja gerado o arquivo .json contendo as especificações das APIs:

dotnet build

Crie um arquivo .spectral.yml com o conteúdo abaixo:

extends: ["spectral:oas"]

Depois de tudo configurado e o arquivo .json com as especificações OpenAPI também gerado, você já pode executar o Linter contra suas especificações:

spectral lint [NOME_DO_SEU_ARQUIVO].json

...

The output will show any issues with the OpenAPI document.

```output

1:1  warning  oas3-api-servers        OpenAPI "servers" must be present and non-empty array.

3:10  warning  info-contact           Info object must have "contact" object.                        info

3:10  warning  info-description       Info "description" must be present and non-empty string.       info

9:13  warning  operation-description  Operation "description" must be present and non-empty string.  paths./.get

9:13  warning  operation-operationId  Operation must have "operationId".                             paths./.get

✖ 5 problems (0 errors, 5 warnings, 0 infos, 0 hints)

Conclusão 💭

Em conclusão, o Scalar surge como uma ferramenta poderosa e intuitiva para a documentação de APIs usando a especificação OpenAPI. Com uma interface moderna, opções de exemplos de uso das APIs em diversas linguagens e plataformas, e uma integração eficiente com a especificação OpenAPI, o Scalar tem a capacidade de melhorar significativamente a experiência de documentação de APIs.

Além disso, a integração com o Spectral, um linter de documentos OpenAPI de código aberto, possibilita a verificação da qualidade dos documentos OpenAPI gerados, assegurando uma documentação mais precisa e de qualidade superior. Portanto, o Scalar se apresenta como uma excelente alternativa ao Swagger para documentação OpenAPI.

Referências

Arquitetura Event-Driven usando AsyncAPI na prática

José Roberto Araújo — Mon, 20 May 2024 17:19:54 +0000

No mundo atual, acelerado e interconectado, os dados se tornaram a força vital das empresas. Como resultado, a necessidade de uma gestão e integração de dados eficazes nunca foi tão grande. É aqui que a Arquitetura Orientada a Eventos (EDA) e a AsyncAPI entram em ação.

EDA é um estilo arquitetural que enfatiza a o funcionamento assíncrono de sistemas distribuídos, reagindo a eventos. Ele permite o processamento de dados em tempo real e ajuda sistemas a se tornarem mais responsívos e ágeis. No entanto, gerir e governar a complexidade desse estilo de arquitetura pode se tornar um grande um desafio. É aqui que entra a AsyncAPI.

AsyncAPI é uma padrão de especificação, de código aberto, que descreve APIs orientadas a eventos. Ele fornece uma maneira padronizada de documentar e comunicar a estrutura e o comportamento de sistemas orientados a eventos. Ao adotar o uso do padrão AsyncAPI, as empresas ganham melhorias sobre a visibilidade dos contratos de mensagens, produtores e consumidores, melhora a governança sobre os dados que estão trafegando dentro da plataforma e aumenta a capacidade de identificação de impactos sobre mudanças.

Nesse post vou usar uma aplicação fictícia de reservar de quartos de hotel, afim de trazer um cenário mais prático e facilitar o entendimento de como aplicar o AsyncAPI em projetos no seu dia a dia.

Caso de uso 📝

Em um sistema de reserva de quartos de hotel, quando um cliente efetua a reserva de um quarto no hotel, esse espaço precisa ser atualizado em toda a plataforma, indicando que a quantidade desse tipo de opção precisa ser decrementada ou não existe mais essa opção disponível para reserva, dada a data selecionada pelo cliente da aplicação.

Imagine que você está desenhando uma solução de comunicação assíncrona para atender ao seguinte caso de uso: Atualizar o sistema quando um quarto for reservado!

Perceba que para realizar a implementação desse requisito será necessário envolver 3 áreas distintas dentro da plataforma, as quais detém a propriedade de 3 microsserviços diferentes: Reserva, Administração Hotel e Pesquisa.

Quando o serviço de Reservas recebe a requisição para confirmar a reserva, é então publicada uma mensagem (neste caso um evento) do tipo ReservaQuartoConfirmada, o serviço de Administração Hotel reage ao evento que foi publicado e atualiza as informações do quarto em seu sub-domínio, o que faz, por sua vez, provocar a publicação de uma outra mensagem diferente, informando que o quarto X foi atualizado, o que por sua vez vai acionar o serviço de Pesquisas que tem a responsabilidade de atualizar a sua fonte de dados, indicando ou a diminuição da quantidade de quartos Xs disponíveis ou remover ele da lista de pesquisa.

Analisando o cenário cima, percebe-se que uma simples ação de reservar um quarto no hotel, vai acionar vários serviços diferentes, responsáveis por atualizar seus respectivos sub-domínios, reagindo à um evento específico dentro da plataforma.

O problema ⚠️

Após ter desenhado, apresentado e validado o design acima, já temos em mãos o desenho da solução pronto para seguir a diante. Certo!?

Não tão rápido assim, como você pensa! 🙂

Em arquitetura de software não devemos, simplesmente, ter um desenho de solução em mãos e seguir para a implementação, antes de verificarmos outros estágios e passos, que nos guiarão durante a fase mais divertida para todos nós desenvolvedores: Realização da solução através de código. 💪🏻

Analisando o contexto da solução, fica fácil percerber que a existência de 3 serviços distintos, provavelmente, também vai nos conduzir para uma tipologia de times onde normalmente temos 3 times diferentes, responsáveis por atuar com cada um desses serviços em separado.

Microsserviços está diretamente relacionado com a parte estratégica do Domain-Driven Design. Contextos Delimitados (Bounded Contexts) são conceitos fundamentais do DDD, dando essencial suporte para tomadas de decisões sobre as fronteiras de cada um dos serviços, e isso também define quais informações são publicadas de um sub-dominio para o meio externo, seja por meio de APIs internas ou seja, no nosso caso aqui desse post, por meio de mensagem em plataformas de mensageria.

Se quiser saber mais sobre como modelar aplicações usando o DDD de forma estratégica, reserve um espaço na sua agenda para ler essa série de artigos aqui.

Na solução proposta no diagrama acima, temos 2 tipos diferentes de mensagens: ReservaQuartoConfirmada e QuartoAtualizado. O contrato dessas mensagens precisa estar consistente e coerente para que ambos os times possa se comunicar de forma eficaz e efetiva, sem ter surpresas por uma eventual mudança, sem haver comunicação entre os times.

Mas como se alcança algo tão organizado quanto o que se tem usando OpenAPI?

Um processo adequado deve estar implementado para descrever os diferentes componentes de um sistema orientado a eventos e suas interações.

A especificação AsyncAPI entra em ação neste ponto.

AsyncAPI specification FTW 🏆

Abaixo está uma citação oficial do site AsynAPI, onde eles definem o que é e para que serve essa especificação:

AsyncAPI is an open-source initiative that seeks to improve the current state of Event-Driven Architectures (EDA). Our long-term goal is to make working with EDAs as easy as working with REST APIs. That goes from documentation to code generation, from discovery to event management, and beyond.

AsyncAPI official site

O padrão AsyncAPI tomou como base muitas das definições e conjunto de dados, presentes dentro da especificação OpenAPI. Dessa forma, a sua curva de aprendizado será muito baixa. Atualmente a versão mais recente do AsyncAPI é a 3.0.

Documentanto a solução arquitetural

Vamos começar a documentação da solução arquitetural, usando as especificações do AsyncAPI 3.0. O objetivo desse processo é criar especificações dos contratos das mensagens e compartilhar essa informação de forma global dentro da empresa. Dessa forma, os times terão confiança em iniciar o processo de implementação, validação, e o mais importante, ter a documentação toda documentada.

Mais a frente neste artigo você vai ter contato com arquivos AsyncAPI já documentados. A especificação do padrão busca definir e anotar os diferentes componentes envolvidos dentro de uma arquitetura orientada a eventos. Os formatos dos arquivos AsyncAPI pode ser construídos usando JSON ou Yaml. Eu vou usar o tipo Yaml neste artigo.

Documentando os componentes

Um dos grandes desafios de uma arquitetura orientada a eventos é identificar, além dos contratos das mensagens, quem são os serviços produtores de mensagens e quais são os consumidores dessa mensagens.

Na especificação AsynAPI esses componentes arquiteturais, chamados Serviços, são conhecidos como Aplicações, conforme está na citação abaixo:

An application is any kind of computer program or a group of them. It MUST be a producer, a consumer or both. An application MAY be a microservice, IoT device (sensor), mainframe process, etc. An application MAY be written in any number of different programming languages as long as they support the selected protocol. An application MUST also use a protocol supported by the server in order to connect and exchange messages*.

— Fonte oficial

Agora é hora de por a mão na massa 😃

Documentando o serviço de Reservas 🏗️

Documentação do serviço de Reservas:

asyncapi: 3.0.0
info:
  title: Serviço de Reservas
  version: 1.0.0
  description: |-
    A API de reservas permite realizar e gerenciar as reservas dos quartos de um hotel.
    ### Veja as funcionalidades desse serviço:

    * Reservar um quarto 🌃  
    * Confirmar a reserva de um quarto 😎
    * Gerir as reservas dos quartos 📈
  license:
    name: Apache 2.0
    url: https://www.apache.org/licenses/LICENSE-2.0
defaultContentType: application/json
servers:
  kafka-cluster:
    host: prod.kafkacluster.org:28092
    protocol: kafka
    description: Cluster Kafka de produção
channels:
  reservaQuartoConfirmada:
    address: reservasdequartos.1.0.event.{roomId}.reservaQuarto.confirmada
    messages:
      reservaQuartoConfirmada:
        $ref: '#/components/messages/reservaQuartoConfirmada'
    description: Tópico responsável por mensagens de reservas confirmadas.
    parameters:
      roomId:
        $ref: '#/components/parameters/roomId'
operations:
  confirmarReservaQuarto:
    action: receive
    channel:
      $ref: '#/channels/reservaQuartoConfirmada'
    summary: >-
      Ação utilizada para realizar a confirmação da reserva de um quarto.
    traits:
      - $ref: '#/components/operationTraits/kafka'
    messages:
      - $ref: '#/channels/reservaQuartoConfirmada/messages/reservaQuartoConfirmada'
components:
  messages:
    reservaQuartoConfirmada:
      name: reservaQuartoConfirmada
      title: Reserva do quarto confirmada
      summary: >-
        Inform about environmental lighting conditions of a particular
        streetlight.
      contentType: application/json
      payload:
        $ref: '#/components/schemas/reservaQuartoConfirmada'
  schemas:
    reservaQuartoConfirmada:
      type: object
      properties:
        quartoId:
          type: string
        entrada:
          type: string
          format: date-time
        saida:
          type: string
          format: date-time
        nomeHospede:
          type: string
        enviadaEm:
          $ref: '#/components/schemas/enviadoEm'
    enviadoEm:
      type: string
      format: date-time
      description: Date and time when the message was sent.
  parameters:
    roomId:
      description: Identificador do quarto.
  operationTraits:
    kafka:
      bindings:
        kafka:
          clientId:
            type: string
            enum:
              - app-reservas

A primeira linha da especificação começa com o tipo de documento, asyncapi, e a versão (3.0.0). Esta linha não precisa ser a primeira, mas é uma prática recomendada.

O objeto info contém as informações mínimas necessárias sobre o aplicativo. Ele contém o título, que é um nome da aplicação (serviço) e sua versão. Embora não seja obrigatório, é altamente recomendável alterar a versão sempre que fizer alterações no serviço.

Seção dedicada a especificar os servidores

A solução apresentada funciona com base em brokers de mensagens, ou servidores de mensagens. Isso obriga que durante a documentação, você identifique e documente qual ou quais servidores de mensagens estão sendo usados pela aplicação (serviço).

servers:
  kafka-cluster:
    host: prod.kafkacluster.org:28092
    protocol: kafka
    description: Cluster Kafka de produção

Usando essa seção do documento, você pode documentar outros servidores de mensagens. Mais detalhes veja na documentação oficial.

Documentando Channels, operations e messages

Fazendo uma tradução direta sobre os termos do título acima, os channels são tópicos ou filas, onde serão armazenadas as mensagens publicadas. As operations são as operações que a aplicação (serviço) vai executar dentro do seu próprio contexto, podendo ser de envio (SEND) ou de recebimento (RECEIVE). Dessa forma, a especificação dá visibilidade sobre onde e como a aplicação vai se conectar e publicar o consumir mensagens.

channels:
  reservaQuartoConfirmada:
    address: reservasdequartos.1.0.event.{roomId}.reservaQuarto.confirmada
    messages:
      reservaQuartoConfirmada:
        $ref: '#/components/messages/reservaQuartoConfirmada'
    description: Tópico responsável por mensagens de reservas confirmadas.
    parameters:
      roomId:
        $ref: '#/components/parameters/roomId'
operations:
  confirmarReservaQuarto:
    action: send
    channel:
      $ref: '#/channels/reservaQuartoConfirmada'
    summary: >-
      Ação utilizada para realizar a confirmação da reserva de um quarto.
    traits:
      - $ref: '#/components/operationTraits/kafka'
    messages:
      - $ref: '#/channels/reservaQuartoConfirmada/messages/reservaQuartoConfirmada'

Cada operação é mapeada para um tópico ou fila, informando qual é a ação específica que vai ser executada SEND ou RECEIVE, além de especificar qual é o schema da mensagem que será ou enviada ou recebida desse tópico ou fila.

O contrato da mensagem é o que estamos buscando documentar, afim de dar visibilidade sobre os dados que estão trafegando de um serviço para o outro, dentro de uma arquitetura distribuída.

Documentando mensagens e o payload

No diagrama da solução há serviços que apenas publica mensagens (eventos) e outros que publicam e consomem mensagens de eventos.

components:
  messages:
    reservaQuartoConfirmada:
      name: reservaQuartoConfirmada
      title: Reserva do quarto confirmada
      summary: >-
        Inform about environmental lighting conditions of a particular
        streetlight.
      contentType: application/json
      payload:
        $ref: '#/components/schemas/reservaQuartoConfirmada'
  schemas:
    reservaQuartoConfirmada:
      type: object
      properties:
        quartoId:
          type: string
        entrada:
          type: string
          format: date-time
        saida:
          type: string
          format: date-time
        nomeHospede:
          type: string
        enviadaEm:
          $ref: '#/components/schemas/enviadoEm'

O trecho documentado acima, você encontra a documentação do payload, ou seja, do schema (estrutura) da mensagem de evento que será tanto publicada quanto consumida em um dado momento do tempo. As definições do esquema de uma mensagem usando AsyncAPI, são 100% compatíveis com o esquema do tipo JSON.

Documentando o serviço Administração Hotel

A documentação do serviço de administração de hotel será similar a documentação do serviço anterior, isso porque a mensagem que é publicada pelo serviço de reservas será a mesma mensagem consumida pelo serviço de administração.

asyncapi: 3.0.0
info:
  title: Serviço de administração do hotel
  version: 1.0.0
  description: |-
    A API de administração do hotel permite realizar e gerir todos os dados relativos ao hotel e os respectivos quartos.
    ### Veja as funcionalidades desse serviço:

    * Registrar quartos 🛏️
    * Gerir dados do hotel 📇
    * Gerir dados dos quartos 📈
  license:
    name: Apache 2.0
    url: https://www.apache.org/licenses/LICENSE-2.0
defaultContentType: application/json
servers:
  kafka-cluster:
    host: prod.kafkacluster.org:28092
    protocol: kafka
    description: Cluster Kafka de produção
channels:
  reservaQuartoConfirmada:
    address: reservasdequartos.1.0.event.{roomId}.reservaQuarto.confirmada
    messages:
      reservaQuartoConfirmada:
        $ref: '#/components/messages/reservaQuartoConfirmada'
    description: Tópico responsável por mensagens de reservas confirmadas.
    parameters:
      roomId:
        $ref: '#/components/parameters/roomId'
operations:
  confirmarReservaQuarto:
    action: receive
    channel:
      $ref: '#/channels/reservaQuartoConfirmada'
    summary: >-
      Ação utilizada para realizar a confirmação da reserva de um quarto.
    traits:
      - $ref: '#/components/operationTraits/kafka'
    messages:
      - $ref: '#/channels/reservaQuartoConfirmada/messages/reservaQuartoConfirmada'
components:
  messages:
    reservaQuartoConfirmada:
      name: reservaQuartoConfirmada
      title: Reserva do quarto confirmada
      summary: >-
        Inform about environmental lighting conditions of a particular
        streetlight.
      contentType: application/json
      payload:
        $ref: '#/components/schemas/reservaQuartoConfirmada'
  schemas:
    reservaQuartoConfirmada:
      type: object
      properties:
        quartoId:
          type: string
        entrada:
          type: string
          format: date-time
        saida:
          type: string
          format: date-time
        nomeHospede:
          type: string
        enviadaEm:
          $ref: '#/components/schemas/enviadoEm'
    enviadoEm:
      type: string
      format: date-time
      description: Date and time when the message was sent.
  parameters:
    roomId:
      description: Identificador do quarto.
  operationTraits:
    kafka:
      bindings:
        kafka:
          clientId:
            type: string
            enum:
              - app-administracao-hotel

Através dessas duas documentações, somos possíveis de descobrir quem são os produtores, consumidores e principalmente quais são os dados que ambos os serviços estão consumindo.

A imagem abaixo ilustra o resultado da documentação usando AsyncApi Studio:

💡Se você quiser se divertir um pouco, pode acessar o AsyncAPI Studio.

Principais conclusões

Adotar o padrão de especificação AsyncAPI em sistemas que aplicação uma arquitetura orientada a eventos (EDA - Event-Driven Architecture), aumenta a consistência, eficiência e a governança entre diferentes times de desenvolvimento.

O ecossistema de ferramentas do AsyncAPI ajuda a acelerar o desenvolvimento de aplicativos, automatizando tarefas tediosas, mas necessárias, como geração de código, geração de documentação, validadores, etc.

A comunidade AsyncAPI está crescendo muito. Sua contribuição para a comunidade será valiosa em termos de criação de melhores aplicativos orientados a eventos.

Referências

Domain-Driven Design Estratégico: Extraindo Sub-domínios com EventStorming

José Roberto Araújo — Tue, 05 Mar 2024 10:18:11 +0000

Os últimos artigos publicados, foram determinantes para a formação da base necessária sobre a compreensão sobre o que é, o como devemos lidar e qual importância tem a parte Estratégica do Domain-Driven Design.

Foram apresentadas algumas técnicas auxiliares que ajudarão a aumentar a compreensão sobre domínios de negócio, e para além disso também melhorar a identificação e compreensão dos requisitos desejados para um produto de software.

Agora, já estamos quase prontos para seguir adiante nessa jornada, aplicando as práticas estratégicas do Domain-Driven Design, vou te fornecer mais ferramentas que te capacitarão a desdobrar o domínio de um sistema proposto: FoodDelivery, identificando, neste artigo, os sub-domínios.

⚠️ Caso você caiu nesse artigo e ainda não entende a definição de sub-domínio, te convido a dar uma pausa nessa leitura e ler o post anterior.

Vamos refinar um pouco mais alguns conceitos básicos e consolidá-los no nosso conhecimento.

O tema sub-domínios leva muitas pessoas ao entendimento de que cada unidade de negócio, dentro de uma empresa, pode ser considerada como um sub-domínio, per-si. Isso é um equívoco comum de acontecer.

Vamos usar o exemplo de um sistema PetClinic. Dentro desse sistema, vão existir várias áreas de negócio, com suas respectivas regras, modelos, pessoas responsáveis, e interações e comunicações entre as outras partes do sistema. Tais áreas podem ser: Gestão de pacientes, agendamento de consultas, registros veterinários de um pet. Olhando para esse sistema, fatalmente o entendimento mais comum seria: Vamos assumir que cada área dessas vai ser nosso sub-domínio 🤔.

💭 Nem sempre tudo aquilo que se observa com frequência é a verdade absoluta das coisas.

Tudo que se vê não é! - Lulu Santos.

Dando continuidade ao exemplo acima, peço que você remova o véu de tudo o que você já viu de projetos de código, supostamente, aplicando técnicas do DDD, e me acompanha cuidadosamente nessa explicação sobre Sub-domínios e Domínios de negócio.

Analisando o fato já externalizado acima, é possível perceber que teríamos, supostamente, 3 sub-domínios distintos: Gestão de pacientes, agendamento de consultas, registros clínicos de um pet.

Vamos levantar algumas provocações sobre as informações que já temos em mãos: Poderia a gestão de pacientes e agendamento de pacientes, pertencerem ao mesmo departamento ou unidade de negócio? Claro que sim! Outra agora mais intrigante: Parte da gestão de pacientes, poderia pertencer a mais de um departamento? Sim ✅. Essa é a razão pela qual, ao modelar o domínio principal de uma empresa, não se deve ficar apegado aos departamentos que a empresa possui, apesar deles te ajudarem a ter uma visão geral de como a empresa está dividida.

Vamos imaginar uma plataforma online de streams de filmes, similar a Netflix. Nessa plataforma haverão separações de áreas (sub-domínios) distintas por funcionalidade, onde cada uma delas vai ter suas próprias: Regras, fluxos, linguagem e implementação.

Catalogo de filmes sub-domínio: Esse sub-domínio tem a responsabilidade de fazer a gestão sobre o catalogo de filmes e séries:
- Registrar um filme/série
- Atualizar informações de um filme
- Categorizar o contéudo (filmes de suspense, comédia, ação)
Player sub-domínio: Esse sub-domínio vai gerir COMO é consumido o conteúdo do catálogo e vai gerir a execução desse conteúdo para o usuário:
- Play (tocar) o conteúdo
- Pause (pausar) o conteúdo
- Tracking time (gestor de tempo) do tempo assistido.
Gestão da conta do usuário sub-domínio: Nesse sub-domínio será onde acontecerá a gestão de conta de cada usuário da platafroma
- Payment method (forma de pagamento)
- Quality of Service (Qualidade do serviço: HD, 4K)
- Address and Contacts (gestão de contatos e endereço)

Ao definir os sub-domínios em um sistema, abre-se espaço para que as pessoas responsáveis pela construção do sistema, tenham uma visão sobre cada uma dessas áreas, e assim possam manter o foco em suas regras e complexidades específicas de cada uma dessas delimitações de unidades. Essa abordagem de descoberta e extração de áreas específicas, permite melhorar a clareza na comunicação entre os times e permite entender até onde cada um pode ir, para além de visualizar os impactos que cada alteração pode implicar uns aos outros.

Existe uma compreensão bastante importante para você ter em mente: nem tudo é da forma como se vê. É preciso explorar um pouco mais as necessidades do contexto e perceber a responsabilidade que ele tem dentro da empresa, pois vão existir momentos em que o que hoje você vê como sendo um sub-domínio, pode se tornar um domínio de negócio, contendo outros sub-domínios. A modelagem abaixo ilustra bem essa visão:

🔎 Observando a modelagem da esquerda, é possível perceber que para a plataforma de FoodDelivery, o negócio não demanda a necessidade de o sub-domínio Order se tornar um domínio de negócio. Já no diagrama da direita, o planejamento da empresa entende que Order terá a responsabilidade de gerir todo o ciclo de realização (fullfilment) de um pedido (order), transformando a área Order em domínio core, e que nesse caso está contendo outros 3 sub-domínios.

Agora eu acredito que tenha ficado claro para você, o que é um Domínio e o que representa um sub-domínio dentro da modelagem estratégica do DDD.

❗Caso tenha ficado alguma dúvida, deixe suas dúvidas nos comentários.

Mas como eu posso aplicar essas técnicas para descobrir e extrair esses sub-domínios no meu projeto?

Para nos ajudar durante a jornada de exploração e identificação de sub-domínios, existem algumas técnicas que podem ser utilizadas, abaixo eu cito 2:

Event Storming
Domain Storytelling

Em projetos que participo, particularmente utilizo o Event Storming, mas o Domain Storytelling se mostra uma excelente técnica para explorar e dar visibilidade aos sub-domínios de um sistema.

Agora vou começar as explorar os diversos comportamentos do sistema, usando Event Storming. Existe muito conteúdo sobre esse tema. Compartilho esse link contendo muitas fontes de estudos sobre o tema.

Basicamente, o EventStorming te permite identificar alguns níveis de abstração:

Visão geral (Big Picture)
Modelagem de processos (Process modeling/Business Flows)
Contextos delimitados (Bounded Contexts)
Personas & Entidades
Políticas (Policies/Rules)

Cada uma desses pontos identidicados, vão colocar luz sobre aspectos da abstração em si, trazendo idéias e entendimentos valiosos, os quais nos permitirão concretizar a modelagem de um sistema.

Iniciando a jornada de descoberta

Antes de iniciar o processo de descobertas, vamos entender rapidamente como EventStorming define os tipos de cartões, o que cada cor representa para um ticket e como eles facilitam a identificação sobre as responsabilidades, durante todo o workshop. Na imagem abaixo você tem uma legenda:

Cada cartão tem a sua responsabilidade e definição dentro do método EventStorming. Abaixo estão descritas as definições de cada um:

Evento (Event)

Eventos são reações à ações que aconteceram no passado. Usamos os verbos escritos no passado, indicando para o receptor do efeito dessa ação, que ela foi executada. Para modelar um processo de negócios, simplesmente organizamos os eventos da esquerda para a direita em uma sequência temporal.

Comando (Command)

Um comando pode ser entendido como uma decisão, ação ou intenção de algo sobre alguma coisa. É a manifestação de interação com o sistema em questão. Comandos são críticos, pois eles representam a intenção de interação de um usuário ou de um outro sistema sobre algum processo. Pro exemplo, quando um usuário expressa a vontade de adicionar um pedido em um e-commerce, é esperado que essa ação seja escrita com o comando: RegistrarPedido.

Ator/Persona (User)

É o agente responsável por interagir com alguma ação dentro de um determinado fluxo de negócio, e também responsável por uma dada decisão. Por meio desse tipo de cartão que se torna possível identificar pessoas que vão interagir com o sistema ou parte de um fluxo.

Modelos de Leitura (Read Model)

Nos permite consultar dados dentro do sistema. Consultamos porque queremos saber algo. Temos perguntas que o sistema pode nos responder, nos permitindo definir alguns limites dentro de uma consulta e retornando os itens que estão dentro dos limites que definimos. O uso dos dados retornados por um modelo de leitura, pode nos ajudar em um processo de tomada de decisão.

Hotspot

Em workshops dessa natureza, é absolutamente natural que alguns conflitos de interesses apareçam durante o mapeamento dos fluxos. Não entenda isso como algo negativo, pois é um evento positivo dentro desse processo. Um conflito pode ser por uma informação incompleta, um entendimento mal explicado, ou seja, pode ser qualquer coisa que leve pessoas a não entrarem em concordância. Para gerir esse tipo de conflito, usamos o cartão do tipo Hotspot, deixando registrado esses pontos de discordância, destacando que há questões que precisam ser resolvidas em um determinado momento durante o desenvolvimento do projeto de software.

Política (Policy)

Uma política define regras que reagem aos eventos ou comandos que são emitidos em fluxos de negócio. Você pode pensar em uma política assim "Sempre que X acontecer, precisamos fazer Y”, eventualmente terminando dentro do fluxo entre um Evento de Domínio e/ou um Comando/ação. É possível utilizar outra expressão, como: Imediatamente à isso. Pense no cenário onde um usuário acabou de resgistrar em uma plataforma. Então Sempre que o usuário se registrar ou Imediatamente ao registro do usuário, o sistema deve enviar um email de boas vindas.

🎉 Agora é hora de começarmos a mergulhar em torno do processo de descoberta e mapeamento do domínio do FoodDelivery. Durante o processo inicial de identificação dos eventos que podem, eventualmente, acontecer dentro de um sistema, cada participante tem a liberdade de poder identificar o evento que ele/a entender ser importante para adicionar ao quadro (físico ou online). A imagem abaixo, facilita perceber que, neste momento, não existe linha do tempo definida, ainda.

Analisando os tickets no quadro acima, você pode observar a disposição potenciais eventos que podem ocorrer dentro de um sistema de FoodDelivery. Veja também que foram permitidos apontar vários tipos de eventos:

Os relacionados ao negócio: Order Placed
E eventos relacionados coisas técnicas. Exemplo: Cart requested payment API

Ainda que sejam cartões de eventos válidos, o nosso foco aqui é sobre os aspectos relacionados ao negócio. Por isso, vamos removê-los desse quadro cima.

Após a limpeza dos cartões que não traz relevância para essa análise, o seu quadro deve se parecer como o da imagem abaixo:

Agora que só temos tickets relacionados ao espaço de negócio, vamos agrupar os tickets com base em alguns critérios:

Identificar palavras semelhantes: Tome cuidado ao analisar o contexto de cada uma delas, afim de classifica-las com base nesse entendimento.
Linha do tempo: Analise os eventos que precisam acontecer antes de acontecer o próximo evento.

Esse agrupamento de contextos permite destacar um esboço dos sub-domínios que esse tipo de sistema pode considerar para funcionar. Colocando os cartões em ordem cronológica, temos a seguinte visão:

Ao final desse trabalho inicial de descoberta e mapeamento de sub-domínios, esses são os contextos que temos para iniciar os trabalhos. Com a evolução do negócio e com a inclusão de novas funcionalidades, os fluxos tendem a mudar em um dado momento do tempo. Mantenha um snapshot (foto) desse esboço, para que você tenha condições de ir evoluindo esse mapeamento no futuro.

Conclusão

Ao final da leitura desse artigo, é fácil perceber que a aplicação das técnicas do Domain-Driven Design não se resumem à apenas programar Entidades, Agregadores, Serviços de Domínio e entidades correlatas. Modelar um domínio de negócio, é uma tarefa essencial para a sobrevivência de qualquer sistema Line-of-Business.

Entender quais ferramentas e técnicas podem ser aplicadas para rodar essa fase inicial, será o seu divisor de águas entre ter um sistema com uma modelagem de negócio ajustada às necessidades da empresa ou simplesmente reproduzir modelos de repositórios do github.

Não menos importante, também foi possível ter uma visão rápida sobre o que significa cada um dos cartões utilizados no método EventStorming. Usando esse conhecimento, avançamos o inicio do brainstorming, levantando todas as possibilidades de potenciais eventos que poderiam ocorrer dentro desse tipo de sistema. Finalizando em um agrupamento contextualizado, começando a dar visibilidade sobre os esboços de sub-domínios.

Agora é seguir para o próximo capítulo dessa série, onde iremos Refinar, ainda mais, essa modelagem 👋🏻.

Referências

Domain-Driven Design Estratégico: Destilando o domínio

José Roberto Araújo — Fri, 16 Feb 2024 12:42:24 +0000

Somos contratados com a responsabilidade de colaborar com a construção de sistemas que estão inseridos dentro de um contexto de negócio, chamado: Domínio.

Operar em diferentes áreas ou nichos de negócio, comumente chamados de Domínio, faz parte do trabalho de qualquer pessoa técnica imergida no desenvolvimento sistemas, independente se está atuando no backend, arquitetura, ou UI. Ter o entendimento do setor no qual se está inserido, é essencial para que qualquer pessoa possa, minimamente, compreender os fluxos das informações e processos.

No primeiro artigo dessa série, foi explorada a importância da descoberta de sub-domínios dentro de um domínio e quais processos podem ser usados para ajudar a encontrar e entender o funcionamento do Business Flow (Fluxo de Negócio) de um determinado setor do mercado, no qual você está trabalhando.

Também, foram citados exemplos de setores do mercado, tais com:

E-Commerce
Tributação
Educação
Logística
Saúde

Cada sub-domínio identificado dentro de cada um dos setores (domínios) acima, são classificados de Arquétipos.

O que são Arquétipos?

Segundo a filosofia, arquétipos são uma espécie de especialização sobre alguma coisa, ou sobre algum comportamento, ou sobre alguma entidade.

Através da perspectiva de Platão, temos o seguinte:

Apesar de ser tentador pensar nas Formas como entidades mentais (ideias) que existem apenas em nossa mente, o filósofo insistiu que elas são independentes de quaisquer mentes (atuais). As Ideias seriam coletivos no sentido de incorporarem as características fundamentais de uma coisa (qualidade universal).

Extrai-se dessa afirmação que devemos ter atenção ao contexto real de onde as coisas estão emergindo, sem o véu do achismo, compartilhando entendimento coletivo sobre como cada área dentro de um domínio funciona.

Entendendo conceitos essenciais

Saber diferenciar o que é um domínio de um sub-domínio, é a chave para o sucesso nessa fase de modelagem estratégica, considerando que a compreensão desses conceitos essenciais vai ajudar não só na identificação de áreas de responsabilidades, como também na organização das topologias dos times e delimitação de fronteiras de responsabilidades e conhecimentos distribuídos dentro das diversas unidades de negócio em uma empresa.

Existe uma grande confusão sobre o que é e como se deve trabalhar com domínios e sub-domínios. Além disso, é comum encontrar e ouvir colegas se referindo à sub-domínios como sendo domínios e vice-versa. - Não se preocupa com isso, porque eu também já cometi esse erro. Por isso escrevi esse post para te ajudar a entender os conceitos de forma correta 🙂.

Domínio

Um domínio refere-se a uma esfera de conhecimento, atividade ou interesse que é sujeita a modelagem. Também pode ser entendido como um setor de negócio.

O domínio define o contexto para o qual um software está sendo desenvolvido e aplicado. Assim sendo, um domínio é composto por conceitos, linguagens específicas, regras e processos que são relevantes para resolver os desafios apresentados por um determinado nicho de negócio.

Como já citado, no inicio desse post, domínios pode ser qualquer setor de negócio:

Agricultura
Saúde
E-Commerce
Logística
Correios

O que diferencia um domínio do outro? Bem, isso vai depender de como cada proprietário de empresas, atuantes em um negócio específico, deseja resolver os desafios impostos pelas leis, regras e processos dentro do domínio que ele escolheu trabalhar.

No setor de Logística, por exemplo, existem vários desafios que podem ser enfrentados para gerir o tracking (acompanhamento) de encomendas e gestão de estoque.

Sub-domínio

Um "sub-domínio" é uma parte menor ou uma subdivisão do domínio principal. Ele pode representar uma área específica dentro do domínio maior ou um conjunto de conceitos especializados dentro do contexto desse sub-domínio.

Sub-domínios são úteis para organizar a modelagem para esse contexto específico, quando o domínio principal é grande ou complexo demais para ser tratado como único. Cada sub-domínio pode ter suas próprias regras, terminologias e especializações de processos.

Ainda podem existir casos em que um sub-domínio pode ganhar notoriedade entre os outros sub-domínios, tornando-se em um domínio propriamente dito, dentro de um domínio principal, tamanha a sua complexidade acumulada, tornando necessário aplicar, novamente, técnicas de descoberta de sub-domínios desse, que antes, era um sub-domínio.

Entendendo o domínio: Food Delivery

Todos nós somos contratados para desenvolver sistemas que estão inseridos em um contexto de negócio muito específico, por mais know-how (conhecimento) que você possa ter nessa área, haverá sempre uma oportunidade para enfrentar desafios novos.

Domain-Driven Design oferece ferramentas úteis e que nos dão o suporte necessário para trabalharmos os principais fundamentos da parte estratégica, criando modelagens que refletem a realidade de um setor de negócio, alinhando os contextos ao desenvolvimento do software que dará vida digital aos processos de uma empresa.

FoodDelivery será o domínio que utilizaremos durante toda a série de posts, guiando você sobre as técnicas e ferramentas adequadas, te ajudando a compreender como lidar com domínios e sub-domínios, contribuindo melhorar a organização e comunicação entre as unidades de negócio em projetos de software de uma empresa. Esse será o Moto dessa série.

Até aqui foram apresentadas muitas teorias! Mas como podemos descobrir e extrair esses processos?

No primeiro artigo, mencionamos várias técnicas úteis para descobertas de processos e sub-domínios, como Event Storming ou Domain Storytelling. Realizando workshops com um grupo reduzido de pessoas especialistas nas áreas importantes a serem debatidas, trabalhando a idealização do funcionamento desses fluxos de negócio.

Não se trata de nenhuma regra que te imponha chegar em uma organização propondo aplicar todas essas técnicas. Contudo, cedo ou tarde a aplicação dessas técnicas e ferramentas será não só útil, mas também necessária. Porém, inicialmente o que normalmente vai acontecer é que você será convidado para participar de rodadas de apresentações das necessidades de negócio da empresa. Algo similar ao diálogo simulado abaixo:

Estamos com a necessidade de criar uma plataforma como serviço que seja usada para realizar pedidos de refeições online. Essa plataforma vai cobrir desde o cadastro de um restaurante como parceiro até a entrega dos pedidos.

Também queremos disponibilizar promoções para os clientes dessa plataforma.

Outro serviço dessa plataforma, será um plano de assinatura, possibilitando os clientes a terem vantagens dentro da plataforma.

E também é preciso que se tenha um dashboard de acompanhamento de vendas por restaurante.

As informações acima podem gerar algum sentimento de desconforto, assumindo que a quantidade de pontos abordados é grande. Quero te dizer que você é uma pessoa com sorte, por ter esse privilégio de ter esses dados em mãos.

Muitas vezes, o que será solicitado à você será para 💥 refazer um sistema já existente ou criar um outro usando outras tecnologias, com base (literalmente falando) no sistema anterior, sem muita explicação e detalhes que poderiam te ajudar a levantar questões.

Então porque é que eu fico feliz com o compartilhamento dessa quantidade de informações? (Alguns poderão dizer o contrário, e achar que não tem muita informação, 🤷🏻). Bem, o momento de você começar a extrair detalhes, está por vir 🙂.

Vamos começar a destilar toda a informação que nos foi passada, começando por essa parte da conversa:

Estamos com a necessidade de criar uma plataforma como serviço que seja usada para realizar pedidos de refeições online. Essa plataforma vai cobrir desde o cadastro de um restaurante como parceiro até a entrega dos pedidos.

Inicialmente, você já toma conhecimento de uma informação muito importante: Criar uma plataforma SaaS para um FoodDelivery. Essa informação é bastante técnica para um inicio de conversa, mas esse contexto de aplicação detectado, favorece entender qual será o modelo de negócio, além de levantar outras perguntas: De que forma está se intencionando monetizar essa plataforma?

Agora vamos para a outra parte da conversa, e analisar mais informações:

Queremos disponibilizar promoções para os clientes dessa plataforma. Além de ter planos de assinatura, possibilitando os clientes a terem vantagens dentro da plataforma.

Fantástico! Algumas afirmações compartilhadas nessa parte da conversa, ajuda a identificar 2 macro-funcionalidades:

Promoções serão criadas e disponibilizadas para os clientes da plataforma e potenciais novos clientes.
Um programa de assinatura será criado e disponibilizado aos clientes, possibilitando aproveitar de benefícios para assinantes.

Esses dois temas identificados acima, vão te favorecer sobre a forma de direcionar o foco para a perspectiva do QUÊ será abordado em uma sessão aplicando Event Storming, por exemplo. Mas o nosso trabalho não para por aqui, e só está começando.

Ainda podemos levantar questões que precisam ser anotadas, afim de serem compartilhadas na sessão de workshop. Existem diferentes perguntas que uma pessoa poderia levantar:

Como as promoções serão integradas nessa plataforma?
Qual será o meio de veiculação dessas promoções? Email? Notificação no portal (aplicação)?
Quando uma assinatura estiver perto de vencer, o que deve ser feito? Enviar uma promoção?
Quando surgir um benefício associado a um plano, como notificar os clientes desse plano?

Essas foram algumas perguntas que podem ser anotadas e levadas para serem discutidas junto aos especialistas de negócio e pessoas envolvidas dentro dessa sessão de Workshop, afim de também contribuir com a construção desse produto. Não se esqueça de não só pensar nessas perguntas, mas também de tomar nota de todas elas.

Vamos analisar outra parte do contexto que nos foi compartilhado:

Quando um plano é contratado, o cliente receberá automaticamente o acesso ao sistema e a todos os benefícios desse plano, além de ser notificado sobre o contrato desse plano.

Até aqui, torna-se possível perceber algumas etapas de processos importantes que nos foram compartilhadas, e dentro desses processos estão contidas ações e eventos que vão dar suporte ao fluxo de negócio desenhado para atender às necessidades da empresa, como:

Preparar as promoções de desconto
Disponibilizar as promoções de desconto
Preparação do contrato de assinatura do plano
Pagamento do valor da assinatura
Liberação de acesso

Ótimo! Agora já conseguimos extrair alguns processos e ações que vão ajudar durante a modelagem dos sub-domínios desse sistema. Mas ainda cabem algumas perguntas:

Ao disponibilizar uma promoção, como será enviada ao cliente? Na App? Email?
Se o cliente quiser usar essa promoção no restaurante físico, será possível? Como?

Se você chegou até essa parte do post, Parabéns! Você conheceu um processo de identificação de macro-funcionalidades, requisitos e aprendeu a explorar algumas questões importantes para enriquecer um workshop de descobertas e detalhamento de processos de negócio.

Agora um conselho que pode ficar aqui é: Utilize essas técnicas usadas durante esse processo de identificação, mas reuna todas as informações levantadas até aqui, de maneira estruturada, afim de te ajudar durante as sessões.

Conclusão

Durante a jornada desse post, cheio de conceitos e abordagens que auxiliam na descoberta de informações necessárias para o desenvolvimento de qualquer sistema ou até mesmo de uma funcionalidade, buscou mostrar a importância de se ter como ferramenta um processo de trabalho objetivo, facilitando a comunicação das pessoas especialistas no negócio, construindo um produto digital consistente.

Reunir as pessoas adequadas dentro de sessões de descobertas, ajuda no entendimento dos fluxos de negócio que estão sendo pensados e desejados, e que serão catalizadores para se ter uma movimentação para o digital, de forma coerente com que está sendo necessário para uma organização.

📌 No próximo post vamos começar a usar esses conhecimentos e partir para um quadro 📋 de descoberta de sub-domínios 😃.

Referências

Domain-Driven Design Estratégico: O Início

José Roberto Araújo — Fri, 09 Feb 2024 10:04:58 +0000

O Domain-Driven Design (DDD) é uma abordagem de modelagem de domínios de negócio que atrai minha atenção desde 2015. Desde então, tenho me aprofundado cada vez mais nos estudos e na prática dessa metodologia, aprimorando minhas habilidades em grandes empresas. Ao longo da minha carreira em grandes empresas, tive a oportunidade de aplicar os princípios do DDD em diversos projetos, aprofundando meu conhecimento e aprimorando minhas habilidades.

A experiência em diferentes empresas com diferentes expectativas de negócio, molda a maneira como se olha para um projeto de tecnologia, onde antes o ponto principal e mais interessante, era conhecer a stack de tecnologia que estava sendo usada e quais eram os projetos de código existentes na empresa. Confesso que essa é a parte que também aquece o meu coração, como developer.

Com o tempo, percebi que a tecnologia, embora fascinante para uma pessoa técnica, é apenas uma ferramenta que viabiliza o sucesso do negócio. No fim das contas, o que realmente importa é o domínio do negócio da empresa. Ou seja, não importan o quão inovadora é a tecnologia, linguagem de programação, cloud provider escolhido, se essas peças técnicas não estão sendo utilizadas para atingir o objetivo do negócio. Por outro lado, se a estrutura da organização da empresa também não estiver sob uma estrutura minimamente organizada, com áreas de atuação bem definidas e sua comunicação não estiver fluindo de forma clara, objetiva e, contextualizada, a tecnologia não vai ajudar nesse sentido.

É aqui onde Domain-Driven Design entra em cena junto com a Lei de Conway.

Primeiro! Entenda o seu domínio 🔍

Durante a minha caminhada profissional, percebo que a aplicação do Domain-Driven Design em projetos, tem se dado muito mais sob a forma tática do que utilizar ferramentas que deem suporte às técnicas de modelagem estratégica. Se você se desafiar a ir ao Github e procurar por DDD ou Domain-Driven Design, vão ser listados vários projetos que usam, basicamente, artefatos táticos: Entidades, Agregados, Objetos de Valor, e que em sua maioria não contextualiza qual o dominio do problema está sendo trabalhado e quais foram as técnicas aplicadas para se chegar àquela estrutura de código. E isso é o que contribui para a geração dos famosos: Projetos DDD. Usar as técnicas táticas não está errado, mas nomear um projeto como usando DDD, apenas por isso, é o que NUNCA deveria ter acontecido na história.

Domain-Driven Design é uma abordagem de modelagem de negócio, o qual tem como fundamento compreender a contextualização de cada área de negócio, suas responsabilidades e objetivos. Cada uma dessas áreas podem ser nomeada de forma diferente, dependendo do tamanho da empresa, algumas chamam de unidades de negócio, e empresas de larga escala, essas mesmas unidades de negócio, são denominadas: Departamentos. A questão essencial por trás desses dois tipos de classificação, é a compreensão sobre o funcionamento do negócio em cada parte da empresa.

Cada empresa trabalha sobre um nicho de negócio específico o que determina qual é o Domínio de atuação daquela empresa. (claro que existem os concorrentes, mas isso não é questão para esse post) Por exemplo:

E-Commerce: este domínio pode incluir compras online, catálogo de produtos, processamento de pedidos, pagamentos e muitas outras partes.
Tributação: neste domínio podemos encontrar áreas como imposto sobre o rendimento, imposto sobre as sociedades, cumprimento fiscal ou política fiscal
Assistência Médica: Aqui pode incluir áreas como gerenciamento de pacientes, agendamento de consultas, registros médicos, gerenciamento de prescrições, etc.
Logística: Nesse tipo de domínio pode existir armazenamento, transporte, gerenciamento de estoque, otimização de rotas ou programação de entrega

Como você pode perceber, a modelagem do negócio está essencialmente ligada ao setor que você está atuando neste momento. Freqüentemente, as empresas que operam no mesmo setor são semelhantes - ou seja, são representadas por modelos ou tipos de negócios básicos e padrão que representam aspectos essenciais de qualquer negócio ou indústria. Tais representações são chamadas de Arquétipos – vou detalhar mais sobre que são Arquétipos, no post abordando os subdomínios. Isso não significa, entretanto, que todas essas partes (Subdomínios) funcionem da mesma maneira.

E isso é algo que precisamos abordar em nossa análise de um domínio de negócios, sempre que construímos (ou reconstruímos) o sistema.

Lei de Conway ⚖️

Toda empresa funciona com base na comunicação entre as pessoas e seus departamentos, o que se torna um fator essencial para uma boa condução de projetos ou uma grande confusão na execução e orquestração de projetos e roadmaps.

É fato que, em arquitetura de sistemas, existe uma máxima chamada: Depende! E essa simples palavra, demanda um ponto de reflexão grande sobre a necessidade de se aplicar alguma regra geral para todas as soluções. No entanto, existe uma um direcionamento que é regido por uma lei, o qual é fácil concordar devido a sua grande importância que é a poderosa: Lei de Conway (no inglês, Conway's Law).

Melvin Conway em 1967, criou essa idéia, que depois vem a se tornar uma Lei, a qual descreve:

”Organizações que desenham sistemas (de qualquer natureza) são obrigadas a produzir designs que são cópias das estruturas de comunicação dessas organizações”

O que a Lei de Conway quer dizer é que é obrigatório que exista uma comunicação limpa, clara e transparente, e que aconteça de forma colaborativa entre as pessoas e departamentos, de forma a assegurar a compatibilidade entre os componentes (seja técnico ou de negócio). A estrutura técnica de um sistema vai refletir as fronteiras sociais das organizações que produzem essa comunicação.

O interessante é que essa Lei foi aplicada, primariamente, no campo da arquitetura de software, entretando Conway direcionou a aplicação da Lei amplamente dentro de uma organização.

Vamos imaginar uma situação hipotética onde você está trabalhando em um time responsável por um subdomínio de Entrega (p*s.: abstraia aqui o tipo do Domínio principal*), dentro desse subdomínio, você vai se especializar em um nicho de conhecimento de negócio muito focado em leis logísticas, regras aplicadas à entregas, tracking das entregas, integração desse subdomínio com parceiros de tracking, dentre outros tantos conhecimentos. Só que agora, o seu time recebeu uma demanda que toca na parte te pagamentos e pedidos. Com essa demanda, chega também a obrigação de ter que atuar em outros subdomínios que você não tem o mínimo conhecimento, mas que a empresa acredita que esse tipo de operação e execução de roadmap, vai ajudar as pessoas a terem um conhecimento holístico do sistema. Legal, na teoria, não é mesmo? Mas claro que isso não funciona!

É aqui que a Lei de Conway entra em cena, ajudando as empresas refinarem as comunicações, separação de responsabilidades de áreas e definir bem as fronteiras entre esses departamentos, afim de facilitar não só o desenho de uma arquitetura consistente, mas também ajudar na organização da topologia dos times. Imagine você uma pessoa da área de Marketing, agora ter que atuar no Financeiro da empresa? 🤔

Utilize ferramentas de modelagem 📝

Bem, se você chegou até aqui, já deu para perceber que Domain-Driven Design vai muito além de Entidades e Agregadores, e até chegar ao momento da implementação, é necessário levantar informações e construir conhecimento sobre o Domínio do negócio onde você está trabalhando!

Uma maneira de facilitar esse processo de descoberta e levantamento de informações sobre o negócio de uma empresa, é a utilização de ferramentas e o agendamento de workshops os quais vão ajudar a unir as pessoas certas e transformar esse momento, em um momento de descoberta transparente e colaborativa.

Na maioria dos casos, eu tenho a prática de descobrir e descrever o caso de negócios (processos) mais crítico. Aquele para o qual o sistema será construído - total ou parcialmente, às vezes partes dos processos de negócios acontecem fora do sistema - um exemplo pode ser um processo em que uma etapa da solicitação é enviada ao sistema jurídico nacional. Devemos esperar algumas semanas pela resposta antes de continuar o processo em nossa empresa.

Propor Workshops com as pessoas adequadas para estarem dentro dessa sessão, vai colaborar com o compartilhamento de conhecimento, isso porque provavelmente vão estar nessa sessão: Especialistas de negócio, pessoas de legal, desenvolvedores de sistemas legados (Ps.: tendo em vista que essas pessoas podem ser as poucas que restam na empresa e que detem o conhecimento desses tipos de sistemas), Arquitetos/Staff/Principals. Essa sessão precisa transmitir o sentimento de que as pessoas passaram a entender o que acontece de uma maneira geral no sistema (mas não serão especialistas em tudo).

Existem alguns métodos que você pode pensar em usar. Existem muitas maneiras diferentes de fazer isso:

Event Storming
Domain Storytelling
User Story Mapping

Qual seria o melhor método a ser utilizado? Para isso depende do contexto do projeto e pessoas envolvidas nessa sessão.

Se o processo for novo, ou se eu obtiver a resposta de que a maioria dos participantes preferiria um workshop de post-its, o método que eu escolheria seria o Brainstorming usando Event Storming, onde todos estão envolvidos.

Caso o processo já existe ou se os participantes preferirem diagramas, eu preferiria um workshop utilizando Domain Storytelling.

Em muitos casos, é simplesmente uma questão de preferência.

Conclusão

Esse post introduziu você sobre o prisma da parte estratégica do Domain-Driven Design. Também ficou claro que até aqui não foi abordado nenhum aspecto tático, diagramas ou designs sobre subdomínios, os tipos de entidades e agregadores dentro desses universos, nem muito menos delimitamos fronteiras através de Bounded Context (contextos delimitados) ou qualquer outro tópico relacionado a arquitetura de software ou padrões arquiteturais.

Surpreso/a sobre esse tipo de abordagem? Se a resposta foi Sim! ÓTIMO! O Objetivo desse artigo foi atingido. Para darmos o próximo passo, precisamos seguir através do caminho da análise do negócio sobre a perspectiva de um determinado domínio e seus respectivos subdomínios, utilizando técnicas e ferramentas que nos dê capacidade de levantar as informações necessárias para construirmos a modelagem do negócio e da arquitetura do sistema, e isso vai dar todas as condições para desenvolver um sistema mais ajustado a realidade do negócio.

No próximo post, vamos mergulhar no universo da modelagem do negócio para um Food Delivery, onde vamos utilizar Event Storming, onde vamos destilar alguns subdomínios.

Referências

System design: PACELC: Uma extensão ao Teorema CAP

José Roberto Araújo — Wed, 07 Jun 2023 12:14:14 +0000

O que se entende sobre o Teorema CAP? E como o Teorema PACELC extende o CAP?

No dia a dia do desenvolvimento de sistemas distribuídos, deveríamos ter a certeza de que muitas falhas, de diferentes tipos, vão acontecer. E esse é um Fato. Ignorar esses eventos abre margem para que as falácias de sistemas distribuídos entre na pauta de discussões sobre os problemas, os quais irão causar prejuízos para a arquitetura do sistema. E isso não é o que se espera de uma arquitetura robusta e tolerante a falhas, caso se tenha em consideração estratégias de design já válidas pela indústria de software.

Abaixo listo as 8 falácias sobre Sistemas Distribuídos:

A rede é confiável
A latência da minha rede é zero
A largura de banda da internet é grande o suficiente
Minha rede está segura
A topologia de redes não vai mudar
Já temos um administrador de redes
Não temos custo de transporte
Minha rede é homogênea

Durante a construção de arquiteturas desse porte, aparecerão tread-offs de todos os tipos e naturezas, e estar preparado para tomar as decisões que melhor se encaixam no seu contexto, vai fazer toda a diferença nos resultados do seu projeto.

Diante de tantos desafios encontrados durante o planejamento, desenho e execução de sistemas distribuídos, existe algum guia, princípios ou alguma forma de balancear a escolha das tecnologias e, além disso, saber onde devo melhorar a arquitetura de um sistema? Considerando as várias características exigidas nesse tipo de solução?

O Teorema CAP conta e resolve apenas uma parte da história. Apesar de atualmente ainda ser um teorema válido, existem muitas críticas a sua volta, devido algumas limitações terem sido detectadas no teorema. Então o que explica o teorema CAP? O que o faz ser uma verdade? Existe alguma alternativa?

Teorema CAP

Criado por Eric Brewer, o Teorema CAP, também conhecido como Brewer's theorem (Teorema de Brewer), apareceu pela primeira vez em 1998 e só foi publicado como teorema em 1999. A primeira versão do Teorema CAP, apareceu com base nos conceitos ACID, Base.

O teorema CAP afirma que um sistema distribuído não pode ter mais do que 2 propriedades, dentre as 3 possíveis: Consistency, Availability e Partition tolerance (Consistência, Disponibilidade e Tolerância a partição)

As combinações dessas escolhas se resumem em: CA, CP e AP. Dentre as combinações, CA é uma das opções que gera alguma confusão em visualizar um caso de uso, tendo em vista que se um sistema não é partition-tolerant, essa característica vai obrigar esse sistema a abrir mão da CONSISTENCY ou da AVAILABILITY em caso de falha na rede.

Portanto, o teorema CAP afirma, resumidamente, que: Na presença de falhas de rede, ou seja, partition failure, um sistema distribuído DEVE escolher entre Consistency ou Availability.

Consistency

Essa propriedade, afirma que todos os nodes possuem os mesmos dados ao mesmo tempo. Isso significa as aplicações pode ler e/ou escrever de/para qualquer um dos nós dentro dessa infraestrutura e, consequentemente, acessarão os mesmos dados.

Availability

Essa propriedade do teorema, afirma que toda operação que for recebida por um dos nós operantes e saudáveis deve retornar uma resposta. Mesmo com um problema severo na rede ou em algum dos nós, a operação recebida pela requisição DEVE terminar e dar uma resposta.

Em resumo, essa propriedade refere-se a capacidade de um sistema permanecer acessível e operável, mesmo que 1 ou mais nós fiquem offline.

Partition tolerance

Essa propriedade do teorema trabalha sobre a perspectiva de falhas de comunicação (ou intermitências/falhas de rede) entre dois nós do sistema. Essa característica fica evidente quando os dois nós estão UP, MAS esses nós não conseguem se comunicar.

Sistemas tolerante a partição (Partition-tolerant) tem a capacidade de sustentar o funcionamento, mesmo em caso de falha de rede, ou seja, falha de comunicação entre os nós.

Os dados são suficientemente replicados em combinações de nós e redes para manter o sistema funcionando durante interrupções intermitentes.

Explicando o Teorema CAP

A palavra TEOREMA assusta quem está conhecendo, pela primeira vez, esse termo, conceitos e abordagens. Até aqui já entendemos que a afirmação do teorema CAP diz que só se pode escolher 2 propriedades/características de sistema, dentre as 3 opções existentes. Por outro lado, existe uma forma que simplifica e ajuda a entender o raciocínio por trás desse teorema.

Facilita pensar no teorema CAP, quando consideramos o (P), representado por Partition tolerance, entre dois nós diferentes. É importante perceber a relevância dessa característica porque, se por meio de uma falha de comunicação, apenas um desses nós tiver seu estado atualizado, o restante ficará inconsistente, o que nos leva a ter uma perda de (C), ou seja, Consistency, no entanto, se tivermos apenas 1 nós consistente, por meio da existência de (P), perdemos (A) Availability.

O Teorema nos diz que não é possível ter um armazenamento de dados que esteja continuamente Disponível (A), Consistente (C) e Tolerante a qualquer falha (P). Porque, para ser consistente, todos os nós precisam ter o mesmo estado de atualização, na mesma ordem de ocorrência. Mas se ocorrer uma falha na comunicação, ou seja, a ocorrência de (P), as atualizações em um dos nós pode não chegar aos outros nós restantes, fazendo com que a aplicação possa ler dados desatualizados, devido ter caído em um dos nós que não foi atualizado anteriormente.

Implicações do Teorema

AP: Sistemas deste tipo respondem a consultas, mas os dados devolvidos podem nem sempre estar atualizados, com atualizações mais lentas dos dados mas “sempre” disponíveis.
CP: Sistemas nessa categoria sempre retornam dados atualizados, mas alguns, ou mesmo todos os nós do sistema podem não responder se forem particionados. Ele fornece atualizações atômicas, mas pode levar a tempos limite.
CA: Sistemas que se encaixam nessa categoria, sempre retornam dados atualizados quando não há partições. Por causa da última limitação, geralmente, tais sistemas são usados apenas dentro de uma máquina.

Críticas ao Teorema

Em sistemas distribuídos, devemos assumir que vamos sim ter falhas de diferentes naturezas e não podemos evita-las, portanto, de acordo com o Teorema CAP um sistema distribuído só deveria escolher entre 2 propriedades: Consistency ou Availability.

Banco de dados que prezam por ACID **(Atomicity, Consistency, Isolation, Durability), focam em garantir a consistência dos dados, enquanto que **BASE (Basically available, Soft-state, Eventually consistent) prezam por retornar os dados presente em um dos nós, sem oferecer a garantia de que esse mesmo dado está presente em todos os outros nós.

O Teorema CAP é criticado por sua simplificação dos acontecimentos e eventos que podem acontecer em uma arquitetura de sistemas distribuídos. Uma das pessoas que compartilhou algumas críticas foi Martin Kleppmann, autor do livro: Designing Data-Intensive Applications.

A escolha entre consistência e disponibilidade realmente só é feita quando ocorre particionamento ou falha entre os nós. Em outros momentos, nenhuma compensação é necessária. Além disso, essas escolhas podem acontecer várias vezes dentro do mesmo sistema, e essas mesmas escolhas podem mudar dependendo da natureza da operação.

Em sua definição original, o teorema CAP ignora atrasos de tempo, embora na prática latência e particionamento são conceitos que estão intimamente ligados. Na prática, a natureza do Teorema CAP ocorre durante um timeout, período em que o sistema deve tomar uma decisão fundamental.

Por fim, todas as três propriedades são mais contínuas do que binárias. Obviamente, a disponibilidade é contínua de 0 a 100 por cento, mas também há muitos níveis de consistência e até mesmo as partições são diferenciadas, incluindo divergências dentro do sistema sobre a existência ou não de uma partição.

Teorema PACELC

O Teorema PACELC, criado por Daniel J. Abadi, é a extensão ao teorema CAP, considerado como abordagem alternativa focada em design de sistemas distribuídos. A fundamentação desse teorema, tem como base o modelo desenhado e definido no teorema CAP, ou seja, todas as propriedades existentes no CAP como: Consistency, Availability e Partition tolerance foram reaproveitadas e, no PACELC foi adicionada a propriedade de Latency (Latência), continuando com uma combinação lógica de exclusão entre esses conceitos.

O idealizador do PACELC, Daniel Abadi, separa as operações em sistemas distribuídos em 2 modos:

Operações **COM **falhas de comunicação (Presença da Partition)

Operações **SEM **falhas de comunicação (Ausência da Partition)

A primeira parte do teorema (PAC) é igual ao teorema CAP, e o ELC é a extensão. Toda a tese assume que mantemos alta disponibilidade por replicação. Assim, quando há falha, prevalece o teorema CAP. Mas se não, ainda temos que considerar a compensação entre consistência e latência de um sistema replicado.

Isso nos leva a raciocinar que as condições para o desenho de um sistema distribuído leva sempre em consideração uma propriedade, antes de todas as outras: Partição (Partition), Ou seja, em havendo uma falha na comunicação (Partition) deve-se escolher uma propriedade entre Disponibilidade (Availability) e Consistência (Consistency), caso contrário, em situação normal de operação do sistema, deve-se escolher entre baixa Latência (Latency) (reduzir o tempo de resposta) e Consistência (Consistency).

Exemplos de base de dados

Cassandra e DynamoDB: São PA/EL, ou seja, eles preferem garantir disponibilidade (availability) ao invés de consistência, quando uma falha de comunicação acontece (Partition), caso contrário, eles optam por baixa latência (Latency)
SQLServer, MySQL, BigTable e HBase: Por exemplo, são sistemas PC/EC: Eles sempre escolherão a consistência, abrindo mão da disponibilidade e menor latência.

Conclusão

O teorema PACELC afirma que, em um sistema que replica dados: os teoremas CAP e PACELC ajudam os sistemas distribuídos a escolher um equilíbrio desejável entre várias características distribuídas, como consistência, disponibilidade, tolerância à partição e latência.

Referências

Event-Driven: Diferenças entre mensagens, eventos e comandos

José Roberto Araújo — Tue, 18 Oct 2022 22:16:10 +0000

A arquitetura de sistemas distribuídos tem como fundamento a comunicação de sistemas no formato assíncrono, baseando-se na troca de mensagens entre sistemas ou mesmo entre seus módulos.

Esse tipo de arquitetura compreende duas variações de mensagens: Eventos e Comandos. Esses dois tipos de mensagens possuem propósitos distintos, a nomeação desses tipos são determinados com base em suas intenções, o proprietário muda mediante o contexto, ou seja, é perceptível que tudo isso faz diferença durante a modelagem de uma mensagem em uma arquitetura Event-Driven e pode, consideravelmente, mudar a experiência do usuário final.

Mensagens

Toda comunicação baseia-se em uma mensagem. Quando você vai ao mercado perto da sua casa e tem dúvida sobre alguma coisa, o que acontece? Acontece, nesse momento, a abertura da comunicação entre duas partes: Você e uma outra pessoa (no mínimo 2 partes precisam existir para acontecer uma comunicação). Quando você quer enviar uma mensagem para alguém, através de algum aplicativo, o que você vai fazer é: Enviar uma mensagem! -- Não existe outra forma de ter comunicação, síncrona ou assíncrona sem existir uma: Mensagem. Sempre vamos ter um Produtor de mensagem e um consumidor dessa mesma mensagem

Em uma arquitetura Event-Driven não é diferente, se uma aplicação/módulo que conversar com outro, precisa existir uma comunicação através de uma: Mensagem.

E ai você pode virar pra mim e dizer: Poxa, bem que essa parte do artigo podia ser ignorada, né? Pois é! poderia ser ignorado SE os fundamentos não fossem tão importantes para o entendimento do todo.

Entender o básico, vai ajudar você no dia a dia a distinguir as diferenças entre os dois tipos de mensagens e entender quando e porquê usar cada um deles, além de entender o impacto que o uso equivocado desses tipos, pode causar na experiência com o usuário da sua aplicaçao, além de trazer impactos em COMO será pensada a arquitetura do sistema seja no Backend ou na experiência com o usuário.

Comandos

Comandos tem um propósito bem definido: Executar um Comportamento. Façamos aqui uma analogia: Quando você entra em um ambiente da sua casa e ele está com as lâmpadas apagadas, o que você faz? Aciona o interruptor e a lâmpada é acesa. O que acontece aqui é que foi enviado uma mensagem no formato de comando, o sistema elétrico reconheceu o comando e executou uma ação que foi acender a lâmpada e a resposta foi ter a lâmpada acesa.

Em uma arquitetura de sistemas distribuídos, também existe o envio de mensagens com a intenção de executar operações dentro de outros sistemas. É interessante observar que existem sistemas ou partes de um sistema que expõem suas capacidades/funcionalidades através de comandos.

Torna-se evidente que, ao executar um comando, o agente de execução espera por uma resposta ao comando enviado. Nesse caso, pode-se associar um comando a uma ação síncrona, onde o agente que enviou o comando fica aguardando o receptor do comando receber o tal comando, validar o payload, executar a operação e retornar dizendo o estado da operação.

Há quem diga que comandos podem ser geridos de forma assíncrona, e digo: Podem! Mas isso muda muito as regras do jogo e também dependendo de onde o comando foi originado, a resposta síncrona precisa acontecer dentro alguns segundos depois que o agente produtor enviou o comando, afim de dar um feedback, mais rápido possível, para quem produziu o comando.

Então pense bem: A origem do comando pode mudar completamente a experiência do usuário e, consequentemente, a abordagem arquitetural.

Abaixo existem 2 fronteiras lógicas diferentes, Pedido e Pagamento, onde cada uma delas envia um comando, mas haverá apenas 1 lugar dentro da arquitetura que terá a responsabilidade de saber reconhecer, validar, executar e responder a um comando. É o consumidor ou o Handler desse comando. É onde a regra do negócio será executada.

Os dois exemplos acima estão usando uma Queue para gerir a produção e o consumo de mensagens desse tipo, afim de focarmos na abordagem da comunicação de sistemas distribuídos.

Comandos podem ser enviados de várias boundaries (limites) diferentes, ou seja, pode existir vários produtores diferentes para um mesmo comando. É quesionável? Bem! Pense em módulo de email. Um email pode ser disparado tanto pelo módulo de pedido, quando pelo módulo de registro de usuário pedindo para confirmar o cadastro. Nesse caso, existem 2 boundaries distintas, que podem enviar comandos para envio de emails.

A forma como se modela e nomeia um comando importa e faz toda a diferença. Perceba nos dois desenhos acima que, em nenhum momento, os comandos foram nomeados como: CriarPedido, AtualizarPedido, DeletarPedido. Essas ações constituem significados específicos e estão ligadas, diretamente, as intenções do negócio. Por isso é importante dar nomes coerentes aos comandos, como: AdicionarPedido, AjustarEstoque, PrepararPedido, EnviarPedido, etc. O comando PrepararPedido, sendo enviado a partir da boundary de Pagamento, quer dizer que o pagamento já foi realizado e que o pedido pode ser preparado para ser enviado.

Eventos

Tudo o que você viu no passado, não pode desvisto. Nada do que aconteceu no passado pode ser desfeito, mas o que aconteceu pode ser notificado/publicado para que alguém que tenha interesse nessa informação possa consumir. Essa é a premissa dos eventos, notificar o mundo externo que algo aconteceu.

Imagine o cenário onde você pede para alguém ir ao mercado comprar alguma comida que você deseja muito, é essa pessoa envia uma mensagem para você, dizendo: Comida comprada!

Os eventos possuem 2 partes, assim como os comandos. A primeira parte é o produtor da mensagem, é quem DETEM o Ownership do contrato da mensagem do tipo Evento, e esse produtor vai notificar o mundo externo sobre algo que já aconteceu. A segunda parte é a parte que consome esses eventos, ou seja, um consumer ou um handler, e que pode realizar alguma operação com base nas informações do payload desse tal evento.

O diagrama abaixo ilustra um único publicador (publisher/producer) de evento e vários consumidores interessados nesse evento:

Através da ilustração do diagrama, é possível perceber que só existe uma única boundary responsável por produzir esse tal evento. É esse Contexto Delimitado (Bounded Context) que tem a lógica de o que produzir, qual payload quer compartilhar (dados) com o mundo externo e quando esse evento deve ser publicado.

O Consumidor de um evento, pode viver dentro de muitos contextos delimitados (bounded context) diferentes, com interesse em consumir o mesmo evento e realizar operações de lógica de negócio dentro de suas fronteiras. Não é obrigado existir sempre um consumidor de eventos, pode existir ZERO ou MUITOS.

Nomear os eventos é essencial para que a comunicação entre as boundaries (fronteiras) faça sentido e seja fácil identificar a intenção de cada evento. Uma vez que os eventos são algo que ocorreu no passado, fica claro que a nomenclatura deles DEVE ficar no passado. Como exemplos temos: PedidoAdicionado, EntregaRecebida, EmailEnviado, PagamentoProcessadoComSucesso. Esses nomes deixam claro qual é a intenção de comunicação dos eventos.

Ao modelar sistemas usando a abordagem do Domain-Driven Design (DDD), é comum perceber que dentro de cada contexto delimitado (bounded context) ações/operações que serão executadas é o geram como resultado, o que chamamos de: Eventos de Domínio. Existem alguns tipos diferentes de eventos e que são usados com finalidades específicas, como por exemplo: Eventos de integração. Em outro artigo, falarei sobre os diferentes tipos de eventos.

Comandos vs Eventos

Objetivo	Comandos	Eventos
Propósito	Executar um comportamento	Expor que algo aconteceu
Proprietário	Propriedade do consumidor	Propriedade do produtor
Consumidores	Tem 1 consumidor	Zero ou muitos consumidores
Produtores	Muitos produtores	Tem 1 produtor
Nomenclatura	Verbo (indicar ação)	Passado

Conclusão

A premissa de uma arquitetura Event-Driven não é apenas lidar com eventos, mas sim modelar a comunicação entre sistemas, através de mensagens, e essas terão suas classificações dependendo da intenção do conteúdo de uma mensagem.

Referências

Junte-se a nossa comunidade

No Youtube você vai encontrar vídeos sobre System Design, Software Architecture. Quer conversar sobre Domain-Driven Design, System Design, Software Architecture? Então faça parte da nossa comunidade no Discord.

Se quiser se aprofundar mais sobre Event-Driven e CQRS, acesse nosso curso de Arquitetura CQRS e acesse o repositório do projeto no Github