Arquitetura OutSystems ODC: como pensar aplicações, bibliotecas e domínios (o que aprendemos colocando em produção)

Quem vem do OutSystems 11 abre o ODC Studio e procura os módulos. Eles não estão lá.

Essa ausência não é detalhe de interface. É uma mudança de modelo mental: sai a organização em módulos e camadas e entra uma arquitetura de aplicações independentes, uma por domínio, cada uma em seu próprio container.

Times experientes em O11 costumam tropeçar exatamente aqui. Não por falta de conhecimento da plataforma, mas porque carregam para o ODC decisões que faziam sentido no modelo anterior.

Este guia de arquitetura OutSystems ODC explica os conceitos que mudam, mostra como aplicar Domain-Driven Design no ODC e conta o que aprendemos desenhando, refazendo e colocando em produção uma arquitetura real.

O que muda na arquitetura do ODC em relação ao OutSystems 11?

No O11, o código é organizado em módulos agrupados em camadas, todos publicados na mesma infraestrutura. No ODC, cada aplicação é um domínio autônomo, empacotado com suas bibliotecas em um container próprio, rodando em Kubernetes na AWS.

Aspecto	OutSystems 11	OutSystems Developer Cloud (ODC)
Unidade de organização	Módulos dentro de aplicações	Aplicações (sem módulos)
Modelo de arquitetura	Camadas com regras de violação entre elas	Domínios com baixo acoplamento
Reuso	Módulos de núcleo e de biblioteca referenciados diretamente	Bibliotecas versionadas e elementos públicos de aplicações
Publicação	Mudanças podem exigir republicar consumidores no mesmo deploy	Cada aplicação é um container separado e é atualizada de forma independente
Runtime	Servidores da plataforma	Separado do ambiente de desenvolvimento, em containers

Na prática, isso significa que a pergunta deixa de ser “em qual camada fica este módulo?” e passa a ser “a qual domínio isto pertence?”.

Aplicação, biblioteca e domínio: os três conceitos que você precisa dominar

Aplicação: um domínio, um container

No ODC, a aplicação contém tudo o que o domínio precisa: dados, lógica, telas, integrações e processamentos em segundo plano, construídos na mesma IDE.

Ao publicar, a plataforma gera o container e o sobe para o ambiente. Por isso, uma aplicação pode ser atualizada sem republicar as outras.

Biblioteca: reuso versionado

Bibliotecas guardam o que é transversal: tema visual, componentes de interface, integrações com sistemas externos (um SAP ou uma API de mercado, por exemplo) e lógica utilitária.

A diferença em relação ao O11 é o versionamento. Quando uma biblioteca muda, cada aplicação consumidora vê que existe uma versão nova e decide se e quando atualizar. Não há atualização em massa obrigatória em produção.

Referência fraca x forte: o que vai junto no container

• Aplicação consumindo aplicação: referência fraca. Cada uma segue no seu container, e a comunicação acontece pelos elementos que a outra expõe.
• Aplicação consumindo biblioteca: referência forte. O código da biblioteca é empacotado dentro do container de quem consome, na versão escolhida.

Onde	O que costuma ser público	Para que serve
Aplicação	Telas, Service Actions, Roles e entidades expostas	Compartilhar dados e operações de um domínio com baixo acoplamento
Biblioteca	Blocks, temas, imagens, actions e estruturas	Reaproveitar componentes e integrações em várias aplicações

Uma regra prática ajuda a decidir: conceito de negócio fica em aplicação; utilidade técnica fica em biblioteca. A análise publicada pelo ITNEXT sobre os conceitos básicos de arquitetura no ODC chega à mesma conclusão.

Como aplicar Domain-Driven Design no ODC na prática

No ODC, cada domínio identificado no Domain-Driven Design (DDD) vira uma aplicação independente. O desenho dos domínios deixa de ser exercício teórico e passa a definir diretamente quantos containers você terá e como eles conversam.

Exemplo: um domínio de usuário consumido por compras e vendas

Imagine duas aplicações, Compras e Vendas, que precisam dos dados de usuário. O usuário não deve ser uma biblioteca, porque é um conceito de negócio. Ele é um domínio, portanto uma aplicação.

Compras e Vendas consomem os elementos públicos da aplicação de Usuário com referência fraca. Dentro de Vendas, outros domínios como Produto e Fornecedor seguem a mesma lógica.

Análise de impacto no deploy: o que acontece quando muda uma assinatura

Se a aplicação de Usuário altera a assinatura de uma action pública, a plataforma faz análise de impacto no momento do deploy e aponta quais aplicações consumidoras precisam ser atualizadas.

A diferença em relação ao O11: a aplicação alterada sobe primeiro, e as consumidoras são atualizadas depois, cada uma no seu container. O deploy deixa de ser um bloco único.

Felipe Horta, OutSystems Champion, explica a anatomia de uma aplicação ODC no módulo 2 do curso gratuito Fundamentos OutSystems ODC.

A ilusão do monolito: o que aprendemos no portal PSC

No projeto do PSC (Precatório Sem Complicação), a Framework recebeu um pedido em dezembro com entrega marcada para fevereiro. Ainda não havia tecnologia definida. A escolha pelo ODC veio do prazo, e o portal foi construído por um desenvolvedor, em menos de dois meses.

O portal atende perfis bem diferentes: advogados, procuradores, cedentes e credores de precatórios. Cada perfil enxerga partes diferentes do mesmo fluxo de negociação.

A primeira impressão: “estamos criando um monolito”

Ao desenhar uma aplicação por domínio, cada uma com seus dados, APIs e telas, a sensação do time, e de arquitetos consultados, foi a de estar construindo vários monolitos lado a lado.

A saída foi voltar à prancheta. O time separou os domínios (usuário, precatórios e documentos anexos), definiu como cada um seria acoplado e quais bibliotecas seriam compartilhadas, como o tema e os componentes comuns. A arquitetura foi refeita duas ou três vezes antes de chegar no desenho final.

A armadilha das permissões entre aplicações

O menu do portal era único, mas navegava entre aplicações de domínios diferentes. Na época, as roles de uma aplicação não eram visíveis para as outras, e o time precisou construir um esquema próprio de permissionamento compartilhado.

Hoje o ODC já permite compartilhar roles entre aplicações. A lição continua valendo: em arquitetura de domínios, autenticação e autorização precisam ser desenhadas antes da primeira tela.

“A gente fez e refez essa arquitetura umas duas ou três vezes, mas no final, o que era mais importante, que era o prazo, a gente conseguiu entregar.”

Felipe Horta, OutSystems Champion e Head de Inovação e Soluções da Framework Digital

Runtime separado: por que isso acelera o time

No ODC, o runtime fica separado do ambiente de desenvolvimento, onde vivem os metadados da aplicação. Na prática, uma versão pode estar em teste enquanto o desenvolvimento da próxima continua, sem conflito.

Somado à infraestrutura, banco de dados, esteira de DevOps e requisitos de segurança já entregues pela plataforma, isso explica por que o time do PSC tinha ambiente de produção disponível no dia zero.

O risco que pouca gente comenta: bibliotecas que consomem bibliotecas

O versionamento de bibliotecas resolve muito, mas cria uma armadilha quando uma biblioteca depende de outra biblioteca.

Em testes publicados no ITNEXT por Dorine Boudry (fevereiro de 2025), uma aplicação acabou usando uma versão de biblioteca diferente daquela que outra biblioteca intermediária esperava. Como o container só leva uma versão de cada biblioteca, a escolha pode não ser a que o time imagina.

Como reduzir esse risco

• Limite os níveis de dependência entre bibliotecas.
• Prefira bibliotecas menores e com propósito único.
• Trate mudanças de comportamento (por exemplo, uma action que passa a lançar exceção) como mudança que quebra, mesmo que a plataforma não acuse.
• Documente qual versão cada aplicação consome.

Checklist: 8 decisões de arquitetura antes do primeiro sprint no ODC

1. Quais são os domínios de negócio e quais deles viram aplicações?
2. O que é conceito de negócio (aplicação) e o que é utilidade técnica (biblioteca)?
3. Quais elementos públicos cada aplicação vai expor e para quem?
4. Como ficam autenticação, roles e permissões entre aplicações?
5. Quais bibliotecas transversais existem (tema, integrações, componentes)?
6. Qual a política de versionamento e de atualização das bibliotecas?
7. Quais integrações com legado passam por cloud connector?
8. O que já existe na Forge e pode ser reaproveitado?

Erros comuns ao migrar o raciocínio do O11 para o ODC

Erro	Consequência	Como evitar
Recriar a lógica de camadas do O11	Aplicações artificiais, sem domínio real	Desenhar a partir dos domínios de negócio
Colocar conceitos de negócio em bibliotecas	Acoplamento forte espalhado por todos os containers	Regra: negócio em aplicação, utilidade em biblioteca
Deixar permissões para depois	Retrabalho na navegação entre aplicações	Desenhar autorização na Sprint Zero
Encadear bibliotecas em muitos níveis	Versões ambíguas no container	Bibliotecas pequenas e poucos níveis
Começar pela tela	Arquitetura refeita no meio do projeto	Modelo de dados e domínios primeiro

Leia mais: OutSystems para empresas: guia completo do O11 e ODC aos agentes de IA

Leia mais: 5 passos para mapear o legado tecnológico AS-IS e isolar dívidas técnicas

Perguntas frequentes sobre arquitetura OutSystems ODC

O ODC tem módulos como o OutSystems 11?

Não. No ODC a unidade de organização é a aplicação, que representa um domínio e roda em seu próprio container. O reuso acontece por bibliotecas versionadas e por elementos públicos de outras aplicações.

Qual a diferença entre aplicação e biblioteca no ODC?

A aplicação concentra um domínio de negócio, com dados, lógica e telas. A biblioteca guarda elementos reutilizáveis, como tema, componentes e integrações, e é empacotada dentro do container de quem a consome.

Como aplicar Domain-Driven Design no ODC?

Cada domínio identificado no DDD vira uma aplicação independente. Domínios compartilhados, como usuário, são consumidos por outras aplicações com referência fraca, mantendo baixo acoplamento.

O que acontece quando uma biblioteca do ODC é atualizada?

Cada aplicação consumidora vê que existe uma nova versão e decide quando atualizar. Não há atualização em massa obrigatória, o que reduz o risco em produção.

Por que a primeira arquitetura no ODC parece um monolito?

Porque cada aplicação concentra tudo o que seu domínio precisa. A sensação passa quando os domínios estão bem separados e as bibliotecas certas concentram o que é transversal.

Migrar do O11 para o ODC exige redesenhar a arquitetura?

Na maioria dos casos, sim. O modelo de módulos e camadas não se traduz diretamente em aplicações por domínio, por isso a migração é uma decisão de arquitetura, não uma atualização de versão.

A arquitetura decide a velocidade da segunda aplicação

A primeira aplicação no ODC sai rápido de qualquer jeito. A plataforma garante isso.

O que separa um portfólio que escala de um que trava é o que acontece depois: se a segunda, a terceira e a décima aplicação reaproveitam domínios e bibliotecas bem desenhados, ou se cada uma recomeça do zero. Pensar a arquitetura OutSystems ODC desde o início não é detalhe técnico. É a decisão que define o ritmo de todo o resto.