Qual é o “Microservice Premium” e quando o custo de adoção de microsserviços se justifica?
É o custo extra e o esforço de orquestrar e gerenciar muitas partes móveis (complexidade de rede, monitoramento, deploy). Justifica-se quando o domínio é complexo, há necessidade de alta escalabilidade independente de componentes, ou quando a autonomia de equipes grandes exige deploys independentes [1-5].
Em uma migração de monolito, como você define os limites dos microsserviços para evitar um “monolito distribuído”?
Utilizando o Bounded Context do DDD. O Bounded Context define um limite de consistência lógica e linguística e é o candidato ideal para se tornar um microsserviço, garantindo alta coesão interna e baixo acoplamento [6-10].
Descreva o padrão Circuit Breaker, seu propósito e seus estados típicos em microsserviços.
É um padrão de resiliência que monitora chamadas a um serviço dependente [11]. Se o serviço falhar repetidamente, o circuito ‘abre’ para falhar rapidamente (fail fast), dando tempo para o serviço se recuperar e prevenindo falhas em cascata. Seus estados são: Closed, Open e Half-Open [12-14].
Qual a importância de backoff exponencial e jitter ao implementar o padrão Retry (tentativas) em comunicação inter-serviços?
O backoff exponencial é aumentar o tempo de espera entre as tentativas de re-tentar a chamada. O jitter é adicionar aleatoriedade a esse tempo. Ambos são essenciais para evitar que múltiplos clientes tentem ao mesmo tempo um serviço que está se recuperando, prevenindo o problema da “manada trovejante” (thundering herd) [15-17].
Como o padrão Bulkhead melhora a resiliência em sistemas distribuídos?
Isola recursos (ex: pools de threads ou conexões) por serviço dependente. Isso garante que a falha ou lentidão em um serviço fique contida em seu ‘compartimento’, sem exaurir os recursos globais do serviço chamador, protegendo outros serviços saudáveis [12, 13, 16].
Explique os Três Pilares da Observabilidade e por que eles são críticos em microsserviços.
São Logs (registros detalhados com timestamp), Métricas (dados numéricos agregados, como latência e taxa de erro) e Traces (rastreamento do caminho de uma requisição end-to-end) [18-21]. São críticos porque a complexidade se move para a rede, exigindo inferir o estado interno a partir dos outputs externos [18, 22, 23].
Qual o papel de um Correlation ID e como ele é utilizado para diagnóstico em arquiteturas de microsserviços?
É um identificador único propagado através de todos os serviços envolvidos em uma requisição. É fundamental para correlacionar os Logs, Métricas e Traces gerados por diferentes serviços, permitindo o rastreamento e a análise da causa raiz em um fluxo distribuído [20, 24].
Diferencie API Gateway e Service Mesh no ecossistema de microsserviços.
O API Gateway é o ponto de entrada único para clientes externos, lidando com roteamento, autenticação, limitação de taxa (rate limiting) e descarregando preocupações transversais [25-27]. O Service Mesh (ex: Istio, Linkerd) é uma camada de infraestrutura que gerencia a comunicação serviço-a-serviço (resiliência, segurança via mTLS, observabilidade) através de proxies sidecar [28-30].
Como microsserviços gerenciam a consistência de dados sem transações ACID distribuídas?
Adotam Consistência Eventual [31, 32]. O padrão Saga é comum, consistindo em uma sequência de transações locais, onde cada passo publica um evento para acionar o próximo, e passos compensatórios são executados em caso de falha para desfazer a operação [31-33].
Descreva o padrão Anti-Corruption Layer (ACL) e cite o padrão de Context Mapping que o utiliza.
ACL é uma camada de tradução (adaptador) que protege o modelo de domínio interno de outro Contexto Delimitado (ou sistema legado) [34-36]. Deve ser usado no padrão de Context Mapping Customer/Supplier ou Conformist para evitar que modelos externos ‘contaminem’ o modelo interno [34, 36].
Qual o propósito principal do padrão Aggregate em DDD e qual é a regra fundamental de consistência transacional associada a ele?
Garantir a consistência transacional de um cluster de Entidades e Value Objects. O Aggregate Root é o ponto de acesso único, responsável por manter as invariantes de negócio. A regra fundamental é: Transações e consistência forte devem ser confinadas dentro dos limites de um Aggregate [10, 37-39].
Qual a diferença crucial na comparação (igualdade) entre uma Entity e um Value Object em DDD?
Uma Entity (ex: Pedido) é comparada por identidade (ID), sendo única ao longo do tempo, mesmo que seus atributos mudem [40-42]. Um Value Object (ex: Dinheiro ou Endereço) é comparado por atributos; é imutável e dois VOs são considerados iguais se tiverem os mesmos valores [36, 41, 43, 44].
O que é um Modelo de Domínio Anêmico e por que é considerado um antipadrão (especialmente em microsserviços)?
É um anti-padrão onde os objetos de domínio (Entidades) contêm apenas dados (getters/setters), sem comportamento ou lógica de negócio, que vaza para serviços procedimentais externos [45-48]. Viola o encapsulamento do DDD e resulta em código menos expressivo e difícil de manter, comprometendo a ideia de microsserviços com ‘endpoints inteligentes’ [45, 49].
O que estabelece a Regra da Dependência na Clean Architecture e como ela é aplicada para isolar o domínio?
Estabelece que as dependências de código-fonte só podem apontar para dentro, em direção às políticas de alto nível (regras de negócio) [50-52]. Isso significa que camadas internas (Entities, Use Cases) não podem ter referências a classes ou frameworks das camadas externas (UI, DB, Web Framework) [50, 52, 53].
Como a Clean Architecture garante a independência de banco de dados e a testabilidade das regras de negócio?
Através da Inversão de Dependência (DIP). A camada de Use Cases define a interface do Repositório (Gateways/Porta), e a camada externa (Adaptadores de Interface/Infraestrutura) fornece a implementação específica do BD. Isso permite testar as regras de negócio passando implementações falsas (mocks/stubs) para a interface [27, 54-56].
Quais são as quatro camadas típicas da Clean Architecture (de dentro para fora)?
- Entities (regras de negócio corporativas); 2. Use Cases (regras de aplicação); 3. Interface Adapters (Controllers, Presenters, Repositórios implementados); 4. Frameworks & Drivers (UI, DB, Web Frameworks) [57-60].
Explique a sinergia entre DDD Estratégico, Microsserviços e Clean Architecture.
DDD Estratégico define o ‘O QUÊ’ e ‘ONDE’ (Bounded Contexts). Microsserviços são o ‘COMO’ da implantação distribuída, transformando Bounded Contexts em unidades implantáveis. Clean Architecture é o ‘COMO’ da estrutura interna, garantindo que o modelo de domínio tático (do DDD) seja testável e protegido de detalhes de infraestrutura [61-63].
Descreva o padrão Strangler Fig (Figueira Estranguladora) para a migração de um monolito.
É um padrão de migração incremental onde novas funcionalidades são construídas como serviços independentes (microsserviços), e um proxy ou API Gateway gradualmente desvia o tráfego do sistema monolítico para os novos serviços, permitindo que o monolito seja ‘estrangulado’ e descontinuado em partes ao longo do tempo [33].
O que são Domain Events e como eles promovem o desacoplamento?
São ocorrências relevantes no domínio de negócio, modeladas explicitamente no pretérito (ex: PedidoConfirmado) [64, 65]. Eles promovem o desacoplamento, permitindo que serviços publiquem eventos de forma assíncrona, notificando outros contextos (microserviços) sobre mudanças de estado sem ter uma dependência síncrona direta [64-66].
Em que cenário a Clean Architecture pode ser considerada overengineering e qual seria a abordagem mais pragmática?
Em projetos muito simples, protótipos de vida curta (MVPs), ou aplicações puramente CRUD. A sobrecarga de interfaces, classes de casos de uso e DTOs pode não compensar [67-70]. Uma arquitetura mais simples em 2-3 camadas, ou o modelo Transaction Script em casos extremos, pode ser mais ágil inicialmente [71].
Qual é o principal critério para decidir se você aplica DDD em um projeto?
A complexidade do domínio de negócio. DDD é recomendado quando o domínio é complexo, cheio de regras, intrincado ou está em constante evolução, pois ajuda a gerenciar essa complexidade e a manter o código alinhado ao negócio [5, 72, 73]. Para domínios triviais ou simples CRUD, o DDD completo é frequentemente um overhead desnecessário [67, 72, 74].
Qual é o papel de um Application Service (Use Case/Interactor) na Clean Architecture e no DDD?
Na Clean Architecture, o Use Case implementa as regras de negócio específicas da aplicação, orquestrando o fluxo de dados e interagindo com as Entidades [57, 75, 76]. No DDD, é similar ao Application Service, que coordena as operações, mas não contém lógica de domínio pura (essa fica nas Entidades/Aggregates) [76, 77].
Descreva os três eixos do Scale Cube (X, Y, Z) e qual deles é a essência dos microsserviços.
Eixo X (Escala Horizontal): Clonagem de serviços idênticos. Eixo Z (Particionamento de Dados/Sharding): Clonagem, mas roteamento baseado em um atributo da requisição. O Eixo Y (Decomposição Funcional) é a essência dos microsserviços: dividir a aplicação em serviços distintos baseados na funcionalidade de negócio [78, 79].
