In un sistema più grande, è molto più semplice:
-
Condividi caratteristiche e codice. Reinventerai la ruota un po 'meno. Ad esempio, se hai dieci applicazioni che devono avere un accesso al database, devi specificare la stringa di connessione in tutte loro , cioè dieci volte. O devi creare una libreria separata e riferirla di nuovo dieci volte.
-
Consolida i flussi di lavoro , incluso il processo di distribuzione.
-
Gestisci il sistema: meno applicazioni da gestire è generalmente più semplice .
-
Unifica l'esperienza utente . Quando un dipendente deve gestire dieci diverse applicazioni, può facilmente perdersi: quale applicazione eseguire per eseguire A? In quale applicazione è disponibile l'opzione B? Ma non overunify . Nessuno apprezzerà Word, PowerPoint, Outlook, Publisher, Visio, Project e Groove come un'unica applicazione monolitica.
In un gruppo di piccoli sistemi, d'altra parte, troverai che:
-
Puoi abbandonare un intero sistema se non ne hai più bisogno. O iniziare da zero se la codebase diventa inutilizzabile nel tempo. Questo è ovviamente vero solo se altri sistemi non si basano su questo, o se l'interfaccia è abbastanza leggera da essere facilmente riscritta in una nuova versione.
-
Puoi formare un team di nuovi sviluppatori e aspettarti da loro di capire l'esistente codebase in meno tempo . Se è parte di un progetto di grandi dimensioni, è probabile che richiederanno più tempo, a meno che la base di codice generale non sia stata eseguita in modo estremamente professionale e refactored molto bene (non ho visto tali codebase nella mia vita).
-
Gli amministratori di sistema saranno in grado di spostare le applicazioni più facilmente . Il sistema più grande, d'altra parte, si adatta bene su più server, oppure no.
-
Gli sviluppatori possono migrare il codice base ai nuovi standard più facilmente . La migrazione di una base di codice di grandi dimensioni fa sempre paura. Invece, quando devi gestire una piccola base di codice, poi un'altra, poi un'altra, e così via, diventa meno spaventosa.
Detto questo, tali confronti funzionano solo in casi generali, ma la tua decisione deve essere presa non dai pool, ma dalle risorse della tua azienda. Come è organizzato? Ci sono molti piccoli team di sviluppatori o alcuni grandi? Esistono delle linee guida rigide sullo stile di codifica e cose simili?
Dipende anche dall'applicazione stessa. Ad esempio, sarebbe assurdo spedire tutte le applicazioni di Microsoft Office come un'unica app. Ma potrebbe anche danneggiare la produttività, ad esempio, per separare Adobe Photoshop in un'applicazione per il disegno e un'altra per il ritocco delle foto. IMO, la decisione di unificare o separare un prodotto deve essere una decisione commerciale, non puramente tecnica.
Infine, voglio anche rispondere al secondo commento della domanda originale:
I'm kindof assuming that linking data within an app is less effort than linking data between apps
Non è sempre vero. Se si tratta, ad esempio, di .NET, non è inusuale spedire una singola applicazione in cui diversi componenti si scambiano tramite WCF. In questo caso, questo è paragonabile a un insieme di applicazioni separate che comunicano tramite WCF.
Naturalmente, quando devi gestire più applicazioni, devi stabilire un modo per comunicare, mentre avere una singola applicazione monolitica non ti costringe a farlo. Ma saresti davvero in grado di scrivere una grande applicazione monolitica?