En un sistema más grande, es mucho más fácil:
Compartir características y código. Reinventará la rueda un poco menos. Por ejemplo, si tiene diez aplicaciones que deben tener acceso a la base de datos, debe especificar la cadena de conexión en todas ellas , es decir, diez veces. O tiene que crear una biblioteca separada y hacer referencia a ella diez veces más.
Consolide los flujos de trabajo , incluido el proceso de implementación.
Administre el sistema: menos aplicaciones para administrar es generalmente más fácil .
Unifica la experiencia del usuario . Cuando un empleado tiene que lidiar con diez aplicaciones diferentes, puede perderse fácilmente: ¿qué aplicación ejecutar para hacer A? ¿En qué aplicación está disponible la opción B? Pero no sobreunifique . Nadie apreciará Word, PowerPoint, Outlook, Publisher, Visio, Project y Groove como una sola aplicación monolítica.
En un grupo de sistemas pequeños, por otro lado, encontrarás que:
Puede abandonar un sistema completo si ya no lo necesita. O comience desde cero si la base de código se vuelve inutilizable con el tiempo. Por supuesto, esto solo es cierto si otros sistemas no dependen de este, o si la interfaz es lo suficientemente ligera como para ser reescrita fácilmente en una nueva versión.
Puede formar un equipo de desarrolladores nuevos y esperar de ellos que comprendan la base de código existente en menos tiempo . Si es parte de un proyecto grande, es probable que requieran más tiempo, a menos que la base de código grande en general se realice de manera extremadamente profesional y se refactorice muy bien (no he visto tales bases de código en mi vida).
Los administradores del sistema podrán reubicar las aplicaciones más fácilmente . El sistema más grande, por otro lado, se escala bien en múltiples servidores o no.
Los desarrolladores pueden migrar la base de código a nuevos estándares más fácilmente . La migración de una base de código grande siempre asusta. En cambio, cuando tiene que lidiar con una pequeña base de código, luego otra, luego otra, etc., se vuelve menos aterrador.
Dicho esto, tales comparaciones funcionan solo en casos generales, pero su decisión no debe tomarse de los grupos, sino de los activos de su empresa. ¿Cómo se organiza? ¿Hay muchos equipos de desarrolladores pequeños o algunos grandes? ¿Existen pautas estrictas sobre el estilo de codificación y cosas similares?
También depende de la aplicación en sí. Por ejemplo, sería absurdo enviar todas las aplicaciones de Microsoft Office como una sola aplicación. Pero también perjudicaría la productividad, por ejemplo, separar Adobe Photoshop en una aplicación para dibujar y otra para retocar fotos. En mi opinión, la decisión de unificar o separar un producto debe ser una decisión comercial, no puramente técnica.
Finalmente, también quiero responder al segundo comentario de la pregunta original:
Estoy asumiendo que vincular datos dentro de una aplicación es menos esfuerzo que vincular datos entre aplicaciones
No siempre es verdad. Si se trata, por ejemplo, con .NET, no es inusual enviar una sola aplicación donde se intercambian diferentes componentes a través de WCF. En este caso, esto es comparable a un conjunto de aplicaciones separadas que se comunican a través de WCF.
Por supuesto, cuando tiene que lidiar con múltiples aplicaciones, debe establecer alguna forma para que se comuniquen, mientras que tener una sola aplicación monolítica no lo obliga a hacerlo. ¿Pero realmente sería capaz de escribir una gran aplicación monolítica?