Modularização funcional¶

Manter a complexidade de um software sob controle é assunto recorrente no desenvolvimento de novos produtos e na sustentação de aplicações existentes. Arquiteturas referenciais como DDD, Clean Architecture propõe, cada um à sua maneira, soluções para a criação de softwares complexos e escalonáveis. Entretanto, a utilização direta dos conceitos e estruturas preconizadas por estas arquiteturas, entretanto, pode conduzir ao mesmo resultado de mistura indiscriminada de aspectos funcionais, não funcionais e estruturais, tornando difícil a manutenção e evolução de longo prazo do software como um todo.

A contribuição pretendida aqui é a de utilização destas arquiteturas na proposição de uma organização que atenda à complexidade, mas que permaneça inteligível para desenvolvedores e demais trabalhadores em software. Para esta contribuição algumas premissas estão consideradas:

Módulos devem ser inteligíveis.
Uma aplicação pode depender de vários módulos.
Um sistema depende de uma ou mais aplicações, mas não depende de um módulo diretamente.
Um ou mais operações e características de um módulo que dependam de Bancos de dados, Caches, Mensageria, Containers devem ser configuráveis e desligáveis.
Devops gerenciam configurações de aplicações e sistemas.
Configurações, código fonte, documentação técnica, documentação de requisitos, evidências de testes devem permanecer acessíveis e de preferência no mesmo SCM.
Cada módulo deve ter um manual técnico.

Heurística para a construção de um módulo funcional¶

Exposição de serviços, configurações e estruturas de dados suficientes para as operações do módulo
Exposição das telas de usuário, se houverem
Unificação interna das operações realizadas através de telas de usuário ou via serviços (API)
Exposição de Mensagens e códigos de erros úteis
Documentação operacional mínima
Documentação mínima para desenvolvedores
Guias de codificação padronizada entre módulos diferentes
Dependência direta apenas de componentes, serviços ou de outros módulos não funcionais
Interligação com outros módulos feitas a partir das API expostas seguindo as regras acima
Configurações de build e depuração

Runtime - Funcionalidade entregue ao sistema pelo módulo¶

É o módulo ou sub-módulo que deve desempenhar os papéis funcionais esperados para este módulo.
Entidades, serviços, configurações e validações devem ser desenhados e codificados levando em consideração apenas aspectos da execução das operações.
Deve oferecer versionamento das estruturas de dados e operações quando isso for aplicável.
Deve oferecer serviços e estruturas de dados que permitam extrações simples das informações derivadas dos dados processados pelos próprio módulo.
Deve evitar extrações analíticas se este não for o propósito do módulo

Administração - Gestão completa de configurações e Entidades do Domínio¶

Deve utilizar o runtime para operações coincidentes
Pode conter entidades, serviços, configurações e validações não disponíveis no módulo de runtime.
Deve ter um público alvo (operações e usuários) menor que o módulo ou submódulo de runtime.
Deve ser o lugar preferencial para extrações e análises mais complexas, preservando o runtime de sobrecarga nos serviços e estruturas de dados.

Hosts - Agrupamento dos módulos¶

Container, Servidores Http ou Host de serviços são os exemplos mais comuns.
Um host tem capacidade de iniciar uma aplicação quando a própria aplicação não é executável pelo Sistema Operacional.
Inicia e interrompe a execução dos aplicativos de um sistema através de interface e configurações bem conhecidas.
Suas características de funcionamento devem ser levadas em consideração no projeto da aplicação que será hospedada.