Guia · Uma aplicação pode concentrar seu deploy e, ainda assim, separar responsabilidades. O monólito modular organiza o código em partes com limites explícitos. Sua utilidade depende da disciplina com que o time mantém esses limites ao alterar o sistema.
Encontre os limites do domínio
Comece pelas capacidades do negócio. Cadastro, cobrança e atendimento têm regras e ritmos de evolução distintos. A divisão deve ajudar a localizar decisões, dados e responsabilidades.
Pastas isoladas, por si só, não garantem modularidade. Observe quais partes mudam juntas e quais conseguem ser compreendidas de forma independente.
Defina contratos entre módulos
Explicite as operações que cada módulo oferece. Evite que consumidores dependam de detalhes internos, como estruturas de persistência ou classes que mudam com frequência.
Um contrato pequeno facilita testes e revisão. Ao modificá-lo, examine quem depende dele e qual comportamento precisa permanecer consistente.
Cuide das dependências
Mapeie dependências circulares e acessos que cruzam fronteiras sem necessidade. O desenho perde valor quando toda mudança exige conhecer o sistema inteiro.
Aplique verificações de arquitetura pertinentes ao projeto. Elas devem detectar uma violação real, como um módulo acessando diretamente a persistência de outro.
Decida a evolução com evidência
Separar um serviço introduz comunicação remota e operação independente. Registre o problema que essa mudança pretende resolver e compare o benefício com seu custo.
Um limite de módulo bem definido pode ajudar uma separação futura. A decisão deve considerar escala, disponibilidade, responsabilidade do time e frequência de mudanças.
Imagem de capa ilustrativa: Unsplash.
