Você já tem as fronteiras

A arquitetura orientada a serviços costuma ser apresentada como um destino. Ela é mais útil como uma pergunta sobre as fronteiras que você já tem, então o primeiro passo é medir as desta aplicação.

Dez contextos

Admin:       60 arquivos   Enrollment:  54 arquivos
Partners:    42 arquivos   Catalog:     21 arquivos
Identity:    19 arquivos   Auth:        18 arquivos
Execution:   14 arquivos   Public:       8 arquivos
Community:    6 arquivos   Media:        1 arquivo

Dez bounded contexts e 243 arquivos Ruby, contados em 2026-09-28 como os arquivos .rb em app/<camada>/<contexto>/. O Admin aparece primeiro porque as telas de autoria de cursos ficam em Admin::Catalog (33 arquivos). Conte esses como Catalog e a ordem muda, então pergunte como o tamanho de um contexto foi contado antes de comparar dois deles.

O MEMORY.md traz a regra que os criou:

"Todo pedaço de código pertence a um domínio nomeado (bounded context). Não há exceções — não adicione controllers, models, serviços ou helpers no nível raiz."

Isso é arquitetura orientada a serviços sem a rede. As fronteiras existem e são respeitadas por convenção, e uma chamada que atravessa uma delas é uma simples chamada de método.

A matriz de acoplamento

Para cada contexto, conte quantos arquivos dele fazem referência a outro contexto pelo namespace. Catalog::Course conta como aresta para o Catalog; Admin::Catalog:: fica dentro do Admin.

flowchart TB
  E["Enrollment 54 arquivos"] -->|21| C["Catalog 21 arquivos"]
  C -->|5| E
  AD["Admin 60"] -->|13| C
  AD -->|8| E
  AD -->|5| PA["Partners 42"]
  PA -->|5| E
  E -->|11| I["Identity 19 arquivos"]
  AU["Auth 18"] -->|10| I
  P["Public 8"] -->|5| C
  X["Execution 14"] -->|5| I
  X -->|4| C
  X -->|3| E
  M["Media 1"]
  AD -->|2| M

O que a matriz diz

Três contextos recebem o tráfego

Catalog, Enrollment e Identity recebem onze das doze maiores arestas: quatro vão para o Catalog, quatro para o Enrollment e três para o Identity. Catalog e Identity são os polos de que a maioria dos contextos depende. O Enrollment é as duas coisas: usa muito o Catalog e o Identity, e é dependência do Admin, do Partners e do Catalog.

Um par é bidirecional

O Enrollment faz referência ao Catalog em vinte e um arquivos, e o Catalog faz referência ao Enrollment em cinco. Uma fronteira atravessada nos dois sentidos é uma costura que foi fechada. É o fato mais importante desta página para tudo o que vem depois.

O Media é uma folha

Um arquivo, referenciado por dois arquivos do Admin, sem referenciar nada. Em termos de grafo, é o que há de mais fácil de extrair aqui. Mas é um arquivo só, e esse é o ponto da lição 4: o candidato que dá para extrair não é o que vale a pena extrair.

O Execution é quase uma folha

Quatorze arquivos. As arestas que saem dele são pequenas (cinco arquivos para o Identity, quatro para o Catalog, três para o Enrollment), e nenhum contexto faz referência a ele em mais de dois arquivos. Ele fica na borda do sistema. A carga de trabalho dele não se parece com a de nenhum outro contexto: ele corrige submissões no servidor, num sandbox, a partir de um job em segundo plano (Execution::GradeSubmissionJob).

A pergunta da SOA

Com fronteiras como essas, a arquitetura orientada a serviços faz uma pergunta só:

Alguma dessas fronteiras deveria virar uma fronteira de rede?

Ela é mais estreita que "devemos construir microsserviços?" ou "o monolito é ruim?": uma pergunta local sobre uma aresta daquele diagrama, com uma resposta que dá para medir. O resto do curso é o método para respondê-la.

A resposta padrão é não, e o padrão acerta muito mais vezes do que a literatura dá a entender. Um monolito modular com dez contextos respeitados já tem quase tudo para que a orientação a serviços serve: raciocinar sobre cada parte isoladamente, donos claros, partes substituíveis. O que falta é deploy independente e falha independente, e a lição 3 trata do quanto isso custa.

O ponto de partida honesto

Esta aplicação tem uma pessoa contribuindo e mais de dois mil commits, e o deploy é feito como uma unidade só.

Nada aqui deveria ser um serviço separado, e dizer isso logo de cara é o que torna o resto do curso útil. O método importa mesmo assim, por dois motivos: é o mesmo método que diz quando a resposta muda, e ele produz um diagnóstico do design atual que vale ter, extraindo algo ou não.

A lição 2 é esse diagnóstico, e ele discorda desta página.

Pontos-chave

• Dez bounded contexts, 243 arquivos Ruby, com fronteiras respeitadas por convenção e nenhuma rede no meio.
• Catalog e Identity são polos; junto com o Enrollment, recebem onze das doze maiores arestas.
• Enrollment e Catalog fazem referência um ao outro: vinte e um arquivos num sentido, cinco no outro.
• O Media é a folha do grafo e tem um arquivo; o Execution é quase uma folha e corrige código no servidor.
• A SOA faz uma pergunta local: uma fronteira específica deveria virar uma fronteira de rede? A resposta padrão é não.