Bounded Contexts livres

Oi! Neste artigo, exploramos o conceito de Bounded Contexts Livres no Domain Driven Design (DDD) e sua relação com o Big Ball of Mud. Assim, definindo contextos que não possuem relações formais com outros, os Bounded Contexts Livres podem ser vistos como sistemas isolados. Portanto, discutimos a importância de práticas e padrões de design para controlar a complexidade do código. Além de manter a clareza e organização nos sistemas de software: Em especial em cenários onde a evolução da arquitetura pode levar a um aumento descontrolado da complexidade.

Aqui no blog temos muitos artigos, sendo muitos deles voltados para o Domain Driven Design, como esse. Fique a vontade para explorar artigos como:

• DDD Estratégico
• DDD Tático
• Bounded Contexts de dependência mútua, 
• Bounded Contexts: Upstream-Downstream

Bounded Contexts livres

Quando se estuda Domain Driven Design rapidamente se observa um conceito chamado Bounded Context ou Contexto Delimitado. Ele considera uma região do software que agrega um conjunto de atividades de processos interrelacionadas. Essa separação é importante para dar maior nível de organização e especialização, além de dar aos usuários e desenvolvedores a possibilidade de uma linguagem ubíqua própria com modelo próprio para cada um.

Há um concenso de existem 9 diferentes tipos de bounded contexts em 3 diferentes tipos de relação. As relações são: dependência mútua, upstream-downstream ou livre. Vamos aqui mergulhar um pouco mais detalhadamente das relações livres.

Embora estejamos falando de “relações” (apenas para ser mais didático), contextos livres na verdade não estão se relacionando. Há – talvez – duas maneiras de observar a coisa: um grande contexto que engloba o sistema inteiro ou pequenos contextos ilhados. Esse primeiro caso é o mais polêmico e vamos ver mais a seguir.

Big Ball of mud

O termo “Big Ball of Mud” (BBOM) foi cunhado por Brian Foote e Joseph Yoder em um artigo de 1999. (Publicado no Proceedings of the 4th Conference on Patterns Languages of Programs [PLoP ’97]).

Portanto, Foote e Yoder usaram o termo para descrever um estilo arquitetural de software que surge naturalmente em sistemas mal projetados ou mal mantidos. Então isso é caracterizado pela falta de estrutura clara, alto acoplamento, e dificuldade de compreensão e manutenção.

Anti-patterns de Brian Foote e Joseph Yoder

No paper eles falaram sobre 7 anti-patterns que são comuns em sistemas. Vamos falar rapidamente sobre cada um deles:

BIG BALL OF MUD (Grande Bola de Lama): sistema que se torna desorganizado e difícil de manter ao longo do tempo devido à falta de planejamento e estruturação adequados;

THROWAWAY CODE (Código Descartável): prática de escrever código com a intenção de descartá-lo após um curto período de uso, muitas vezes para atender a prazos apertados ou prototipagem rápida;

PIECEMEAL GROWTH (Crescimento Fragmentado): processo de desenvolvimento de software em que novas funcionalidades são adicionadas de forma incremental e muitas vezes sem uma visão global ou planejamento adequado, levando à complexidade e desorganização do sistema;

KEEP IT WORKING (Deixe Funcionando): abordagem de manter um sistema funcionando sem fazer mudanças significativas na estrutura ou no design, mesmo que isso signifique adicionar soluções temporárias ou “remendos”;

SHEARING LAYERS (Camadas Desgastantes): situação em que diferentes partes de um sistema evoluem em ritmos diferentes, resultando em diferentes camadas de abstração que podem se tornar incompatíveis ou difíceis de integrar;

SWEEPING IT UNDER THE RUG (Varrendo para Debaixo do Tapete): prática de ignorar problemas de design ou qualidade de código, em vez de resolvê-los, na esperança de que não causem problemas no futuro;

RECONSTRUCTION (Reconstrução): Sugere a reconstrução completa de um sistema de software desorganizado ou obsoleto, geralmente como último recurso, quando as abordagens de manutenção e refatoração não são mais viáveis.

Big Ball of Mud e o Domain Driven Design

Entenda que sistemas pequenos, na minha visão, não devem ser feitos com base no DDD. Tem-se muito trabalho, exige-se muita organização para não obter os benefícios. Entretanto, sistemas maiores podem usar essa abordagem ou outras que tentem controlar a evolução da complexidade do código. O Big Ball of Mud, para os autores, é o sistema que evolui e cresce mas não adota práticas para esse controle.

Podemos entender que esse cenário é um Bounded Context livre, podendo ser único ou um pedaço do sistema, mas sem conexões formais e de difícil manutenção.

Trabalhando com múltiplos contextos

Veja que o BBom é, em essência, um sistema ruim. Há situações em que temos diversos contextos, alguns se comunicando com outros utilizando abordagens de upstream/downstream, por exemplo. Entretanto algumas abordagens exigem a criação de anticorruption layers, definição de linguagens publicadas, entre outros que podem podem aumentar os custos da empresa. Assim, entenda que em muitos casos um bounded context implica em ter um time de desenvolvimento e um time de operações para sua existência.

Uma possibilidade quando estamos falando de otimizar a relação entre os contextos é formalmente dizer que esses contextos não vão se conectar.

Separated ways

Essa abordagem é muito interessante ao considerar que um contexto A não vai se falar com o contexto B. Portanto eles poderão crescer de maneira livre e independente, com uma linguagem ubíqua própria, modelo próprio e evitando potenciais custos de tradução entre eles. Essa abordagem é comum hoje em dia (2024) quando pensamos em microcomponentização através de microserviços baseados em eventos, por exemplo.

Conclusão de Bounded Contexts livres

Em conclusão, os Bounded Contexts Livres representam uma abordagem interessante no desenvolvimento de software, permitindo uma visão mais flexível e modular do sistema. No entanto, é essencial ter em mente os desafios associados, especialmente em relação à manutenção da clareza e organização do código, para evitar que esses contextos se tornem “Big Balls of Mud”. Portanto, adotar práticas e padrões de design adequados, como os propostos pelo DDD, pode ser fundamental para controlar a complexidade e garantir a sustentabilidade dos sistemas de software ao longo do tempo.