Usando pacotes (gemas, ovos, etc.) para criar arquiteturas dissociadas

O problema principal

Vendo o bom apoio mais modernas plataformas de programação tem para gerenciamento de pacotes (pense gem, npm, pip, etc), faz sentido para projetar um aplicativo ou sistema ser composto por pacotes desenvolvidos internamente, de modo a promover e criar uma arquitetura flexível?

Exemplo

Um exemplo disso seria criar pacotes para acesso ao banco de dados, bem como para autenticação e outros componentes do sistema. Naturalmente, eles também usam pacotes externos. Em seguida, seu sistema importa e usa esses pacotes - em vez de incluir o código em sua própria base de código.

Considerações

Para mim, parece que isso promoveria a dissociação de código e ajudaria a manutenção, quase do tipo de aplicativo baseado na Web versus aplicativo de desktop (as atualizações são aplicadas quase automaticamente, base de código única para funcionalidade única etc.).

Parece um conceito de design racional e são? Isso é realmente usado como uma maneira padrão de estruturar aplicativos hoje?

Eu já estive envolvido em projetos como esse duas vezes agora (ambos usando nuget com .NET), e eu diria que, no geral , é uma boa idéia. Mas sua milhagem pode variar.

Não pense por um minuto que é uma panacéia, que resolverá todos os seus problemas sem causar novos. O gerenciamento de versões ganhará uma camada totalmente nova de complexidade. Você precisará lidar com problemas de dependência de versão que você nunca soube que existiam e terá momentos em que amaldiçoará a decisão porque precisará atualizar quatro pacotes diferentes por causa de um problema. pequeno bug que você precisa corrigir e liberar rapidamente.

Por outro lado, você está certo ao dissociar as coisas muito bem. A menos que você exagere, provavelmente encontrará mais ocasiões em que "oh, isso funcionou muito bem" do que "isso acrescentou muito esforço". Se você tem código compartilhado entre vários aplicativos, é particularmente eficaz porque você pode atualizar facilmente seus aplicativos independentemente.

E, se você for como eu, começará rapidamente a escrever aplicativos de teste que usam seus pacotes, para remover camadas inteiras de aplicativos do seu processo de busca de erros. E isso, por si só, pode valer mais do que os custos.

Esta é uma boa ideia, apesar de tudo. Você precisará pensar em configurar um repositório interno de pacotes (geralmente chamado de "repositório de artefatos" no mundo Java ou "servidor pypi" no mundo Python), para manter os pacotes que não deseja ou não pode ' t liberar como código aberto.

Como o @pdr observou, esteja preparado para ter sua própria dependência , onde uma alteração em um pacote requer primeiro outra em outro pacote, e isso significa não apenas alterar uma linha de código, mas testá-la, possivelmente obtendo as alterações aceitas, construindo um release e enviando o release para o repositório de pacotes mencionado acima. E depois mudar o que você pretendia mudar.

A única receita que posso fornecer da minha experiência para tentar minimizar isso: não confie apenas em abstrair conceitos comuns de seus pacotes em um pacote "comum" ou "estrutura" . Isso pode parecer algo muito objetivo, mas levará a um pacote de monstros que precisa de mudanças e lançamentos frequentes e possivelmente contraditórios. Muito melhor, pense nas funcionalidades do seu sistema e crie um pacote auxiliar para cada uma delas, conforme descrito na sua pergunta.

Além disso, o principal benefício que você obterá é que seus aplicativos são isolados de (muitas) dependências, para que você possa trocá-los sem problemas.