Em um sistema maior, é muito mais fácil:
Compartilhe recursos e códigos. Você reinventará a roda um pouco menos. Por exemplo, se você tiver dez aplicativos que devem ter acesso ao banco de dados, precisará especificar a cadeia de conexão em todos eles , ou seja, dez vezes. Ou você deve criar uma biblioteca separada e referenciá-la dez vezes novamente.
Consolide os fluxos de trabalho , incluindo o processo de implantação.
Gerenciar o sistema: menos aplicativos para gerenciar geralmente são mais fáceis .
Unifique a experiência do usuário . Quando um funcionário precisa lidar com dez aplicativos diferentes, ele pode se perder facilmente: qual aplicativo executar para executar A? Em qual aplicativo está disponível a opção B? Mas não exagere . Ninguém apreciará o Word, PowerPoint, Outlook, Publisher, Visio, Project e Groove como um único aplicativo monolítico.
Em vários sistemas pequenos, por outro lado, você encontrará que:
Você pode abandonar um sistema inteiro se não precisar mais dele. Ou comece do zero se a base de código se tornar inutilizável ao longo do tempo. Obviamente, isso só é verdade se outros sistemas não confiarem nesse sistema ou se a interface for leve o suficiente para ser facilmente reescrita em uma nova versão.
Você pode formar uma equipe de desenvolvedores novos e esperar que eles entendam a base de código existente em menos tempo . Se fizer parte de um projeto grande, é provável que exijam mais tempo, a menos que a grande base de código geral seja feita de maneira extremamente profissional e refatorada muito bem (eu nunca vi essas bases de código na minha vida).
Os administradores do sistema poderão realocar os aplicativos mais facilmente . O sistema maior, por outro lado, pode ser escalado bem em vários servidores ou não.
Os desenvolvedores podem migrar a base de código para novos padrões com mais facilidade . Migrar uma grande base de código é sempre assustador. Em vez disso, quando você precisa lidar com uma pequena base de código, depois outra, depois outra, e assim por diante, isso se torna menos assustador.
Dito isto, essas comparações funcionam apenas em casos gerais, mas sua decisão deve ser tomada não a partir de pools, mas dos ativos da sua empresa. Como é organizado? Existem muitas equipes pequenas de desenvolvedores ou algumas grandes? Existem diretrizes estritas sobre o estilo de codificação e coisas semelhantes?
Também depende da própria aplicação. Por exemplo, seria absurdo enviar todos os aplicativos do Microsoft Office como um único aplicativo. Mas também prejudicaria a produtividade, por exemplo, separar o Adobe Photoshop em um aplicativo para desenho e outro em retoque de fotos. Na IMO, a decisão de unificar ou separar um produto deve ser uma decisão comercial, não puramente técnica.
Por fim, também quero responder ao segundo comentário da pergunta original:
Estou assumindo que vincular dados em um aplicativo é menos esforço do que vincular dados entre aplicativos
Nem sempre é verdade. Se você está lidando, por exemplo, com o .NET, não é incomum enviar um único aplicativo no qual diferentes componentes estão sendo trocados pelo WCF. Nesse caso, isso é comparável a um conjunto de aplicativos separados que se comunicam através do WCF.
Obviamente, quando você precisa lidar com vários aplicativos, precisa estabelecer uma maneira de eles se comunicarem, enquanto ter um único aplicativo monolítico não o força a fazer isso. Mas você realmente seria capaz de escrever um grande aplicativo monolítico?