DEV Community: Felipe

Holonomic Systems: What Arthur Koestler Can Teach Us About Software Architecture

Felipe — Thu, 25 Dec 2025 14:39:09 +0000

The Dilemma Every Architect Faces

How do we build systems that are cohesive enough to be understandable and decoupled enough to evolve independently?

On one side: the monolith — initial simplicity that becomes a nightmare.
On the other: microservices — flexibility that can become operational complexity.

What if there was a mental framework that balanced these forces? There is. And it comes from an unexpected place: a 1967 philosophy book.

Arthur Koestler and the Concept of Holon

In 1967, Hungarian-British philosopher Arthur Koestler published "The Ghost in the Machine". Frustrated with simplistic dichotomies, he coined a new term: holon.

Etymology

holos (Greek): "whole", "entire"
suffix -on: connotes "particle" (like proton, neutron)

Holon = an entity that is simultaneously a complete WHOLE and a PART of something larger.

The Fundamental Duality

"Every holon has two tendencies: an integrative tendency to function as part of a larger whole, and a self-assertive tendency to preserve its individual autonomy."
— Arthur Koestler

Koestler called this the "Janus effect" — like the Roman god with two faces. Every holon looks simultaneously inward (its integrity) and outward (the larger system).

Holons in Nature

Your body is a perfect holarchy:

ORGANISM
    └── ORGAN (heart)
          └── TISSUE (cardiac muscle)
                └── CELL
                      └── ORGANELLE

Each level is:

Autonomous: functions on its own
Integrated: contributes to the whole

When this balance breaks? Cancer — cells that maintain autonomy but lose integration.

The Problem with Traditional Architectures

Poorly Structured Monolith

Components are just parts — no real autonomy:

Can't test in isolation
Can't deploy independently
Failure propagates everywhere

Suppressed the self-assertive tendency.

Poorly Implemented Microservices

Dozens of services with synchronous HTTP forming a "distributed monolith":

Chained synchronous calls
One failure brings down all
Complexity without benefit

Nominal autonomy, chaotic integration.

Self-Contained Systems: Holonomy in Practice

German company INNOQ formalized the concept of Self-Contained Systems (SCS).

Characteristics

Principle	Description
Autonomous	Complete web application
Vertical Slice	UI + logic + own data
No sync in request/response	Doesn't call other SCS synchronously
Single team	One team per SCS

The Golden Rule

Other SCS should not be accessed synchronously within the request/response cycle.

If you need data from another SCS → have a local copy updated via events.

SCS vs Microservices: An Honest Comparison

What is NOT a difference

❌ "SCS uses async, microservices uses sync"

Wrong. Modern microservices use Kafka, RabbitMQ, event-driven architecture.

The real differences

Aspect	SCS	Microservices
Quantity	5-25	50-500+
UI	Mandatory	Optional
Granularity	Business domain	More granular
Sync in request	Prohibited	Allowed

Anatomy of a Software Holon

┌─────────────────────────────────────────────┐
│              HOLON: Orders                  │
├─────────────────────────────────────────────┤
│  PUBLIC INTERFACE                           │
│  • REST/GraphQL API                         │
│  • Published events (Kafka)                 │
│  • Consumed events                          │
├─────────────────────────────────────────────┤
│  DOMAIN LOGIC                               │
│  • Business rules                           │
│  • Workflows/Sagas                          │
├─────────────────────────────────────────────┤
│  PERSISTENCE                                │
│  • Own database                             │
│  • Replicas of external data                │
├─────────────────────────────────────────────┤
│  SELF-REGULATION                            │
│  • Health checks                            │
│  • Circuit breakers                         │
│  • Metrics                                  │
└─────────────────────────────────────────────┘

The Dependency Rule

// ❌ WRONG
import { InventoryService } from '../inventory';

// ✅ CORRECT
await eventBus.publish({
  type: 'OrderCreated',
  payload: order
});

Holons don't import other holons directly.

Challenges of Asynchronous Communication

1. Event Ordering

Sent: [A, B, C]
Received: [A, C, B] 😱

Solution: Kafka guarantees order per partition.

2. Duplication (at-least-once)

if (await alreadyProcessed(event.id)) return;
await process(event);
await markAsProcessed(event.id);

3. Eventual Consistency

Accept it as reality. UI shows "processing..." when needed.

4. Distributed Debugging

Correlation ID in all logs + Jaeger/Zipkin.

When to Use (and When Not)

✅ Use when:

Multiple distinct domains
Teams need independence
High availability is critical
Differentiated scale per domain

❌ Avoid when:

Small system, single team
MVP or proof of concept
Strong consistency is required
No experience with distributed systems

Evolution Path

Modular Monolith
       ↓
Separate schemas
       ↓
Introduce messaging
       ↓
Complete Holonomic System

Evolve when the pain justifies it, not before.

Conclusion

Holonomy isn't a silver bullet. It's a mental framework.

What Koestler taught us: resilient systems maintain balance between being a whole and being a part.

Monoliths, microservices, SCS — all can work. Wisdom lies in choosing right for the context.

References

Koestler, Arthur. "The Ghost in the Machine" (1967)
SCS Architecture
Microservices.io - Saga Pattern
Apache Kafka

"The whole is more than the sum of its parts, but the parts are more than fragments of the whole."

Liked it? Leave a ❤️ and share with anyone facing architecture decisions!

Want to discuss? Comment below 👇

Sistemas Holonômicos: O Que Arthur Koestler Pode Ensinar Sobre Arquitetura de Software

Felipe — Thu, 25 Dec 2025 14:37:48 +0000

O Dilema que Todo Arquiteto Enfrenta

Como construir sistemas que sejam coesos o suficiente para serem compreensíveis e desacoplados o suficiente para evoluírem independentemente?

De um lado: o monolito — simplicidade inicial que vira pesadelo.
Do outro: microservices — flexibilidade que pode virar complexidade operacional.

E se existisse um framework mental que equilibrasse essas forças? Existe. E vem de um lugar inesperado: um livro de filosofia de 1967.

Arthur Koestler e o Conceito de Holon

Em 1967, o filósofo húngaro-britânico Arthur Koestler publicou "The Ghost in the Machine". Frustrado com dicotomias simplistas, ele criou um termo novo: holon.

Etimologia

holos (grego): "todo", "inteiro"
sufixo -on: conota "partícula" (como próton, nêutron)

Holon = uma entidade que é simultaneamente um TODO completo e uma PARTE de algo maior.

A Dualidade Fundamental

"Cada holon tem duas tendências: uma tendência integrativa de funcionar como parte de um todo maior, e uma tendência auto-afirmativa de preservar sua autonomia individual."
— Arthur Koestler

Koestler chamou isso de "efeito Janus" — como o deus romano de duas faces. Todo holon olha simultaneamente para dentro (sua integridade) e para fora (o sistema maior).

Holons na Natureza

Seu corpo é uma holarquia perfeita:

ORGANISMO
    └── ÓRGÃO (coração)
          └── TECIDO (músculo cardíaco)
                └── CÉLULA
                      └── ORGANELA

Cada nível é:

Autônomo: funciona por si
Integrado: contribui para o todo

Quando esse equilíbrio quebra? Câncer — células que mantêm autonomia mas perdem integração.

O Problema das Arquiteturas Tradicionais

Monolito Mal Estruturado

Componentes são apenas partes — sem autonomia real:

Não testam isoladamente
Não deployam independentemente
Falha propaga para tudo

Suprimiu a tendência auto-afirmativa.

Microservices Mal Implementados

Dezenas de serviços com HTTP síncrono formando um "distributed monolith":

Chamadas síncronas em cadeia
Falha de um derruba todos
Complexidade sem benefício

Autonomia nominal, integração caótica.

Self-Contained Systems: Holonomia na Prática

A empresa alemã INNOQ formalizou o conceito de Self-Contained Systems (SCS).

Características

Princípio	Descrição
Autônomo	Aplicação web completa
Vertical Slice	UI + lógica + dados próprios
Sem sync no request/response	Não chama outros SCS sincronamente
Equipe única	Um time por SCS

A Regra de Ouro

Outros SCS não devem ser acessados sincronamente dentro do ciclo request/response.

Se precisa de dados de outro SCS → tem uma cópia local atualizada por eventos.

SCS vs Microservices: Comparação Honesta

O que NÃO é diferença

❌ "SCS usa async, microservices usa sync"

Errado. Microservices modernos usam Kafka, RabbitMQ, event-driven architecture.

As diferenças reais

Aspecto	SCS	Microservices
Quantidade	5-25	50-500+
UI	Obrigatória	Opcional
Granularidade	Domínio de negócio	Mais granular
Sync no request	Proibido	Permitido

Anatomia de um Holon de Software

┌─────────────────────────────────────────────┐
│              HOLON: Pedidos                 │
├─────────────────────────────────────────────┤
│  INTERFACE PÚBLICA                          │
│  • API REST/GraphQL                         │
│  • Eventos publicados (Kafka)               │
│  • Eventos consumidos                       │
├─────────────────────────────────────────────┤
│  LÓGICA DE DOMÍNIO                          │
│  • Regras de negócio                        │
│  • Workflows/Sagas                          │
├─────────────────────────────────────────────┤
│  PERSISTÊNCIA                               │
│  • Banco próprio                            │
│  • Réplicas de dados externos               │
├─────────────────────────────────────────────┤
│  AUTO-REGULAÇÃO                             │
│  • Health checks                            │
│  • Circuit breakers                         │
│  • Métricas                                 │
└─────────────────────────────────────────────┘

A Regra de Dependência

// ❌ ERRADO
import { EstoqueService } from '../estoque';

// ✅ CORRETO
await eventBus.publish({
  type: 'PedidoCriado',
  payload: pedido
});

Holons não importam outros holons diretamente.

Desafios da Comunicação Assíncrona

1. Ordenação de Eventos

Enviado: [A, B, C]
Recebido: [A, C, B] 😱

Solução: Kafka garante ordem por partição.

2. Duplicação (at-least-once)

if (await jaProcessado(evento.id)) return;
await processar(evento);
await marcarProcessado(evento.id);

3. Eventual Consistency

Aceite como realidade. UI mostra "processando..." quando necessário.

4. Debugging Distribuído

Correlation ID em todos os logs + Jaeger/Zipkin.

Quando Usar (e Quando Não)

✅ Use quando:

Múltiplos domínios distintos
Times precisam de independência
Alta disponibilidade é crítica
Escala diferenciada por domínio

❌ Evite quando:

Sistema pequeno, equipe única
MVP ou prova de conceito
Consistência forte é requisito
Sem experiência em sistemas distribuídos

Caminho de Evolução

Monolito Modular
       ↓
Schemas separados
       ↓
Introduzir mensageria
       ↓
Sistema Holonômico Completo

Evolua quando a dor justificar, não antes.

Conclusão

Holonomia não é bala de prata. É um framework mental.

O que Koestler nos ensinou: sistemas resilientes mantêm equilíbrio entre ser todo e ser parte.

Monolitos, microservices, SCS — todos podem funcionar. A sabedoria está em escolher certo para o contexto.

Referências

Koestler, Arthur. "The Ghost in the Machine" (1967)
SCS Architecture
Microservices.io - Saga Pattern
Apache Kafka

"O todo é mais do que a soma das partes, mas as partes são mais do que fragmentos do todo."

Gostou? Deixe um ❤️ e compartilhe com quem está enfrentando decisões de arquitetura!

Quer discutir? Comenta aí embaixo 👇