Screaming Architecture é um conceito introduzido pelo renomado desenvolvedor de software e líder inovador Robert C. Martin, muitas vezes referido como "Tio Bob". O termo pode parecer pouco convencional, mas representa um princípio poderoso no design de software, com foco em fazer com que a arquitetura de um sistema reflita as principais preocupações e casos de uso do aplicativo. Em termos mais simples, a arquitetura do seu software deve “gritar” sua intenção e propósito.

Neste guia abrangente, exploraremos os fundamentos da Screaming Architecture, como ela contrasta com a arquitetura de software tradicional, sua importância no design orientado a domínio e como você pode implementar essa arquitetura em seus projetos. Também abordaremos exemplos práticos e cenários onde a Screaming Architecture pode melhorar a legibilidade do código, a capacidade de manutenção e a escalabilidade de longo prazo.

Por que arquitetura "gritante"?

A ideia por trás da Screaming Architecture é que a estrutura primária de sua base de código transmita imediatamente seu propósito de negócios. Isto contrasta com as arquiteturas tradicionais, que podem enfatizar estruturas técnicas, ferramentas ou outras preocupações secundárias. Na Screaming Architecture, as preocupações de domínio têm precedência sobre os detalhes de implementação.

Tio Bob Martin ilustrou isso com uma analogia: imagine caminhar até um prédio e ver sua arquitetura. Sem precisar de uma placa, muitas vezes você pode saber se é uma biblioteca, uma escola ou um escritório. O mesmo deve se aplicar à arquitetura de software. Ao observar a estrutura de pastas e o design de um aplicativo, você deve entender imediatamente para que serve. Se você estiver construindo um sistema de contabilidade, a arquitetura deve gritar “contabilidade”, não “Django”, “Spring Boot” ou “React”.

Os problemas com arquitetura centrada em estrutura

Em muitos projetos, o foco em estruturas tecnológicas ofusca a lógica de negócios ou de domínio. Você encontrará estruturas de arquivos como:

controladores/ serviços/ repositórios/ modelos/

controllers/

services/

repositories/

models/

Embora esses diretórios sejam úteis, eles descrevem funções técnicas em vez de refletir o problema central que o software resolve. Por exemplo, esta estrutura informa que o sistema usa MVC (Model-View-Controller), mas não fornece informações sobre se o sistema lida com dados financeiros, gerenciamento de usuários ou criação de conteúdo.

A armadilha da estrutura

A ênfase excessiva em estruturas resulta em bases de código onde a lógica de negócios é obscurecida por padrões técnicos. Um sistema construído em torno de convenções de estrutura torna-se fortemente acoplado a essas estruturas. Se você quiser mudar estruturas ou pilhas de tecnologia, a refatoração se tornará um grande esforço. A Screaming Architecture defende manter a lógica do seu domínio limpa e separada, de modo que a escolha da estrutura se torne um detalhe de implementação, e não a estrutura central da sua base de código.

Arquitetura gritante em design orientado a domínio (DDD)

Domain-Driven Design (DDD) e Screaming Architecture geralmente andam de mãos dadas. DDD é uma abordagem para desenvolvimento de software que enfatiza a colaboração entre especialistas técnicos e de domínio, e se concentra na modelagem da lógica de negócios central de uma forma que se alinhe estreitamente com as operações do mundo real.

Na Screaming Architecture, o modelo de domínio e a lógica de negócios estão no centro do aplicativo, e todo o resto – estruturas, bancos de dados, UI e serviços – torna-se periférico. A ideia principal é que a estrutura do código reflita o modelo de domínio em vez dos detalhes técnicos de implementação.

Veja como você pode estruturar seu projeto de uma forma que "grite" sua intenção usando princípios orientados por domínio:

/src /contabilidade Ledger.cs Transação.cs Conta.cs TaxService.cs /vendas Pedido.cs Fatura.cs Cliente.cs Política de desconto.cs

controllers/

services/

repositories/

models/

Neste exemplo, os nomes das pastas refletem diretamente as preocupações comerciais: contabilidade e vendas. Cada classe específica de domínio, como Ledger, Transaction e Order, é colocada em seu contexto de domínio relevante. Essa estrutura deixa imediatamente claro do que se trata o sistema e onde cada componente se encaixa.

Exemplo de código 1: uma estrutura simples centrada no domínio

Considere um aplicativo de comércio eletrônico que lida com pedidos e estoque. Com a Screaming Architecture, a estrutura de pastas deve refletir a lógica de negócios e não as funções técnicas:

/src /pedidos Pedido.cs OrderService.cs PedidoRepositório.cs /inventário Item de inventário.cs InventárioService.cs InventárioRepositório.cs

controllers/

services/

repositories/

models/

Aqui está um exemplo de código básico do contexto de pedidos:

Ordem de classe pública { ID do Guid público {obter; definir; } public DateTime OrderDate { obter; definir; } public List Itens { get; definir; } public decimal TotalAmount { get; definir; } Pedido público (List itens) { Id = Guid.NewGuid(); OrderDate = DateTime.Agora; Itens = itens; ValorTotal = CalculaTotal(itens); } decimal privado CalculaTotal(List itens) { retornar itens.Soma(item => item.Preço * item.Quantidade); } } classe pública OrderItem { string pública NomeDoProduto { get; definir; } preço decimal público {obter; definir; } public int Quantidade {obter; definir; } }

controllers/

services/

repositories/

models/

Neste código, o conceito de domínio (Order) está na frente e no centro, com lógica de suporte como OrderService e OrderRepository mantida em arquivos separados. A lógica de negócios (CalculateTotal) faz parte da entidade Order, em vez de ficar oculta em um serviço ou controlador.

Evitando distrações técnicas

Frameworks e bibliotecas são cruciais para o desenvolvimento de software, mas não devem ditar como sua lógica de negócios é estruturada. A Screaming Architecture defende a transferência de detalhes técnicos como controladores HTTP, camadas de persistência e estruturas de banco de dados para a periferia.

Aqui está um exemplo que contrasta as arquiteturas tradicionais e gritantes:

Arquitetura Tradicional:

/src /controladores OrderController.cs /serviços OrderService.cs /repositórios PedidoRepositório.cs /modelos Pedido.cs OrderItem.cs

controllers/

services/

repositories/

models/

Embora isso seja tecnicamente correto, não informa para que serve o sistema. A estrutura de pastas não revela nada sobre o domínio. É um sistema de comércio eletrônico? Uma aplicação financeira? É impossível saber sem se aprofundar no código.

Arquitetura Gritante:

/src /pedidos OrderController.cs OrderService.cs PedidoRepositório.cs Pedido.cs OrderItem.cs /inventário InventárioController.cs InventárioService.cs InventárioRepositório.cs Item de inventário.cs

controllers/

services/

repositories/

models/

Essa estrutura esclarece imediatamente que o sistema trata de pedidos e estoque. Se você adicionar mais domínios no futuro (por exemplo, clientes, pagamentos), eles terão um lugar dedicado na arquitetura.

O papel da arquitetura limpa

Screaming Architecture geralmente se alinha com os princípios mais amplos da Arquitetura Limpa do Tio Bob. A Arquitetura Limpa promove uma separação de preocupações, concentrando-se em garantir que as regras de negócios sejam independentes de estruturas, UI e bancos de dados. A Screaming Architecture vai um passo além, sugerindo que a estrutura do projeto deve revelar a lógica central do negócio.

Aqui está uma rápida recapitulação da Arquitetura Limpa:

Entidades: lógica e objetos de negócios principais.

Casos de uso: regras de negócios específicas do aplicativo.

Interfaces: Gateways para frameworks e sistemas externos.

Frameworks e Drivers: UI, bancos de dados e outros componentes externos.

Em um projeto de Arquitetura Limpa, conceitos de domínio como Pedido, Cliente e Fatura fazem parte da camada central. Frameworks como ASP.NET Core, Django ou Rails são relegados às camadas externas, servindo como mecanismos para entregar a funcionalidade principal.

Exemplo de código 2: Aplicando arquitetura limpa na arquitetura Screaming

Em uma arquitetura Screaming, você estruturaria os casos de uso e entidades de uma forma que refletisse o domínio de negócios. Vamos estender nosso exemplo de comércio eletrônico:

/src /pedidos CreateOrderUseCase.cs PedidoRepositório.cs Pedido.cs OrderItem.cs /inventário AdicionarInventoryItemUseCase.cs InventárioRepositório.cs Item de inventário.cs

controllers/

services/

repositories/

models/

Aqui está um exemplo de caso de uso para criar um pedido:

classe pública CreateOrderUseCase { privado somente leitura IOrderRepository _orderRepository; privado somente leitura IInventoryService _inventoryService; public CreateOrderUseCase (IOrderRepository orderRepository, IInventoryService inventárioService) { _orderRepositório = pedidoRepositório; _inventoryService = inventárioService; } Execução de ordem pública (List itens) { //Garante que todos os itens estejam disponíveis no inventário foreach (var item em itens) { _inventoryService.CheckInventory(item.NomeProduto, item.Quantidade); } var pedido = novo pedido(itens); _orderRepository.Save(pedido); ordem de devolução; } }

controllers/

services/

repositories/

models/

Neste exemplo, CreateOrderUseCase faz parte da lógica do domínio e interage com OrderRepository e InventoryService para atender à necessidade comercial de criar um pedido.

Benefícios da arquitetura Screaming

Legibilidade aprimorada: qualquer pessoa que abrir sua base de código entenderá imediatamente o que o sistema faz.

Separação de preocupações: a lógica de negócios permanece isolada dos detalhes técnicos, tornando mais fácil alterar estruturas ou tecnologias posteriormente.

Escalabilidade: À medida que o sistema cresce, a estrutura do domínio permanece consistente, permitindo fácil adição de novos recursos e módulos.

Manutenção: a lógica do domínio é mais fácil de manter quando está claramente separada das dependências e estruturas externas.

Framework Agnostic: Screaming Architecture permite que a lógica de negócios permaneça portátil em diferentes pilhas técnicas, evitando o acoplamento rígido com qualquer estrutura específica.

Críticas à arquitetura gritante

Embora Screaming Architecture tenha muitos benefícios, não deixa de ter suas críticas:

Complexidade percebida: Desenvolvedores não familiarizados com design orientado a domínio podem achar a separação da lógica de domínio dos detalhes técnicos desnecessária ou excessivamente complexa para aplicações pequenas.

2

. Despesas gerais: Em pequenos projetos ou aplicações CRUD simples, implementar a Screaming Architecture pode parecer um exagero.

Curva de aprendizado: Para equipes acostumadas com abordagens que priorizam a estrutura, a adoção da Screaming Architecture requer uma mudança de pensamento que pode levar algum tempo para ser internalizada.

Quando usar a arquitetura Screaming

Screaming Architecture é particularmente útil nos seguintes cenários:

Sistemas controlados por domínio: aplicativos com regras de negócios complexas e lógica de domínio.

Projetos de longo prazo: sistemas que devem evoluir ao longo do tempo, onde a escalabilidade e a capacidade de manutenção são críticas.

Desenvolvimento multiplataforma: sistemas que podem mudar de estrutura ou plataforma, tornando essencial uma separação clara da lógica de negócios.

Conclusão

Screaming Architecture é mais do que apenas um nome cativante; é uma filosofia que defende tornar a lógica de negócios central a parte mais proeminente de sua base de código. Ao focar em conceitos de domínio em vez de estruturas técnicas, os desenvolvedores podem construir sistemas que sejam mais legíveis, fáceis de manter e escaláveis ​​no longo prazo. Esteja você trabalhando em um aplicativo web simples ou em um sistema empresarial complexo, a adoção da Screaming Architecture pode levar a um código mais limpo e focado que expressa claramente seu propósito.

Para saber mais sobre Screaming Architecture, você pode conferir algumas referências e leituras adicionais:

Arquitetura Limpa de Robert C. Martin

Design baseado em domínio por Eric Evans

Blog do tio Bob sobre código limpo

Ao adotar os princípios da Screaming Architecture, você pode criar bases de código que não apenas funcionam, mas também "gritam" sua intenção.