# Microservice Chassis

## Preocupações Transversais

Cada microsserviço precisa de diversas funcionalidades comuns para rodar corretamente em produção. Essas funcionalidades não pertencem ao domínio do negócio, mas são essenciais para operação, observabilidade, segurança e suporte.

Essas funcionalidades são chamadas de **Cross-Cutting Concerns**, pois atravessam todos os microsserviços da arquitetura, independentemente de sua responsabilidade de negócio.

Elas incluem, por exemplo, controle de configuração, logging, métricas, monitoramento, health check, segurança e lógica de build.

<figure><img src="https://2751774268-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxndCEXu1WY8Bo9gAhe4i%2Fuploads%2FCDgnkiZBe0VkBiFpdJLf%2Fimage.png?alt=media&#x26;token=0f67a650-46e1-45ff-9f38-fdb08977a15e" alt=""><figcaption></figcaption></figure>

O diagrama com **três microsserviços independentes**, cada um contendo internamente:

* Lógica de negócio
* Lógica de build
* Preocupações transversais

Embora os serviços resolvam problemas de negócio diferentes, todos acabam implementando as mesmas responsabilidades técnicas internas.

***

## Não agregam valor ao negócio

reocupações transversais e lógica de build são necessárias, mas não entregam valor direto ao negócio. Elas existem para viabilizar o funcionamento do serviço em produção, não para diferenciar funcionalidades do sistema.

Quando cada microsserviço trata essas responsabilidades de forma isolada, surgem duplicações, inconsistências e aumento do custo operacional. O esforço técnico cresce sem impacto proporcional na entrega de valor.

***

## O conceito de Chassi

O conceito de **chassi** surge para resolver esse problema. A proposta é concentrar e padronizar tudo aquilo que não pertence ao domínio do negócio, mas que é necessário para todos os microsserviços.

Um único chassi reduz duplicidade, melhora a consistência técnica e otimiza custos. Os times deixam de resolver repetidamente os mesmos problemas estruturais e passam a focar no que realmente importa.

<figure><img src="https://2751774268-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxndCEXu1WY8Bo9gAhe4i%2Fuploads%2Ff43HaJMvz1l2cFADS3MX%2Fimage.png?alt=media&#x26;token=9e9d2118-a4f5-4cfc-8754-283248f5d702" alt=""><figcaption></figcaption></figure>

Um único chassi otimiza os custos e padroniza

***

## Microservice Chassis Pattern

O **Microservice Chassis Pattern** formaliza essa abordagem.

Nesse modelo, as preocupações transversais e a lógica de build padrão são extraídas dos microsserviços e disponibilizadas por meio de um chassi comum, geralmente distribuído como biblioteca ou dependência compartilhada.

Os microsserviços continuam responsáveis pela sua lógica de negócio, mas passam a incorporar funcionalidades técnicas de forma padronizada, com menor acoplamento operacional e maior previsibilidade arquitetural.

<figure><img src="https://2751774268-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxndCEXu1WY8Bo9gAhe4i%2Fuploads%2FDZNbyncVxJvnlVvOmG7A%2Fimage.png?alt=media&#x26;token=1bdf7e1a-380c-4419-80aa-45c39aa89abb" alt=""><figcaption></figcaption></figure>

O diagrama representa um chassi central contendo lógica de build padrão e preocupações transversais comuns. Três microsserviços dependem desse chassi e incorporam essas funcionalidades de forma consistente, mantendo apenas suas particularidades de negócio e eventuais customizações específicas.

## Spring Boot e Spring Cloud como Chassis

Sob essa ótica, **Spring Boot e Spring Cloud podem ser encarados como um Microservice Chassis**.

Esse ecossistema resolve nativamente diversas preocupações transversais comuns em arquiteturas de microsserviços, oferecendo uma base sólida e amplamente adotada para construção de serviços produtivos.

Mais do que frameworks, eles funcionam como uma fundação técnica que impõe padrões e boas práticas de maneira consistente.

{% embed url="<https://spring.io>" %}

<figure><img src="https://2751774268-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxndCEXu1WY8Bo9gAhe4i%2Fuploads%2Fsl9jmyvdLYN0m5BHWWLf%2Fimage.png?alt=media&#x26;token=736d960e-7282-404f-8ccc-951aba3e2430" alt=""><figcaption></figcaption></figure>

{% embed url="<https://spring.io/projects/spring-boot>" %}

<figure><img src="https://2751774268-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxndCEXu1WY8Bo9gAhe4i%2Fuploads%2FkeF25eqRQrGtyO99IvkY%2Fimage.png?alt=media&#x26;token=1c5453a5-5b99-45b6-9f6f-260eadcbc308" alt=""><figcaption></figcaption></figure>

{% embed url="<https://spring.io/projects/spring-cloud>" %}

<figure><img src="https://2751774268-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxndCEXu1WY8Bo9gAhe4i%2Fuploads%2F0gKSCc0FWiyGxkIC4kn4%2Fimage.png?alt=media&#x26;token=b5e67bec-d1d4-4323-ac0a-7d04c3b8c999" alt=""><figcaption></figcaption></figure>

## Trade-offs

A adoção de um chassi traz ganhos relevantes, mas também impõe restrições.

Existe maior dependência estrutural: mudanças no chassi impactam múltiplos microsserviços. A evolução precisa ser controlada, versionada e bem governada.

Os times perdem liberdade para decisões técnicas individuais, mas em troca ganham padronização, previsibilidade e menor custo de manutenção.

Em ambientes pequenos, a adoção de um chassi pode representar complexidade desnecessária. Ele se justifica principalmente quando o custo da repetição começa a comprometer a escala.

## Consideração final

O Microservice Chassis Pattern não é uma solução de curto prazo. Ele emerge naturalmente conforme a arquitetura cresce.

Em ambientes com múltiplos microsserviços e equipes, a ausência de um chassi resulta em desgaste técnico progressivo.

Arquitetura madura não busca inovação constante.\
Busca estabilidade, disciplina e capacidade de evoluir sem atrito.
