Em artigos anteriores, falei sobre o conceito de Arquitetura Gritante e sobre a biblioteca MediatR. Neste arquivo vou mostrar como podemos usar o MediatR para pôr em prática os conceitos de Arquitetura Gritante, resultando numa camada de aplicação mais voltada às operações de negócio.
Estrutura de aplicação
Uma estrutura de aplicação que tenho testado e gostado bastante, é baseada no modelo apresentado por Jason Taylor no NDC Sydney 2019, que aplica Arquitetura Limpa a um projeto com ASP.NET Core. Aliás, em breve vou escrever um post falando sobre Arquitetura Limpa aqui no blog.
A estrutura da solution, conforme estamos usando em alguns projetos na Ambev Tech é a seguinte:
Estrutura da solution de um microserviço
Nessa estrutura, a camada Application fica responsável pelas operações de negócio que a aplicação suporta, e mapeia os casos de uso que implementa. Ela trabalha em conjunto com o Domain para executar as operações necessárias e seu foco é gerar valor de negócio para o cliente. Abaixo, podemos ver como é organizado o projeto Application:
Organização das operações de negócio no projeto Application
A seguir, vamos explorar como essa estrutura ressalta as operações de negócio.
Primeiro nível de pastas - Entidades impactadas
Como podemos ver, temos as pastas de primeiro nível discriminando as entidades que serão impactadas. Normalmente, essas pastas acabarão sendo um mapeamento direto das entidades do domínio. Exemplos são Clientes, Pedidos, CarrinhoCompras, etc.
Pastas de primeiro nível
A única exceção, como pode ser visto, é a pasta Common, que contém infrasestrutura do próprio projeto Application, como configuração do FluentValidation e afins.
Segundo nível de pastas - Operações de negócio
Já as pastas de segundo nível são responsáveis por descrever operações de negócio disponibilizadas pela aplicação. Essas operações costumam mapear muito bem para Casos de Uso, como discutido no artigo sobre Arquitetura Gritante, pois são descritos do ponto de vista do usuário da aplicação. Independente de o usuário ser uma pessoa ou outro serviço, as operações aqui são descritas do ponto de vista do usuário. São pequenos serviços que a aplicação presta.
Pastas de segundo nível
Esta noção de recortar a aplicação por operações de negócio, também conversa com um conceito chamado Vertical Slicing, e é explorado nessa palestra do Jimmy Bogard no NDC Sydney 2018.
Terceiro nível - Implementação das operações de negócio
Tudo o que tiver dentro de uma pasta de segundo nível, trata de realizar aquela operação de negócio. Como podemos ver na imagem a seguir, temos um Request do MediatR, uma validação desse request usando FluentValidation, e mais um namespace com outras classes necessárias para realizar a operação.
Terceiro nível
Se você quiser ver como é a implementação de um desses requests do MediatR, pode conferir meu artigo sobre ele.
Conclusão
Seguindo esta estrutura, os diretórios de primeiro e segundo nível do projeto Application passam a expressar valor de negócio. Eles são um mapa de tudo que a aplicação é responsável por fazer, e de quais entidades eles impactam.
A maior vantagem desta abordagem é a clareza que ela proporciona. Tudo o que a aplicação faz, e também o que ela não faz, fica óbvio numa inspeção rápida. Tal qual uma planta de apartamento, está tudo ali. A aplicação grita o que faz e seu valor fica óbvio de imediato.