A medida que los sistemas de software crecen, aparece una tensión difícil de evitar: cada aplicación necesita resolver sus propios problemas, pero muchas de las capacidades que necesita ya existen en algún lugar de la organización. Una aplicación de ventas necesita consultar clientes, una aplicación de facturación necesita conocer esos mismos clientes y diferentes procesos necesitan consultar productos, contratos o pedidos. Si cada aplicación implementa de nuevo esas capacidades, terminamos multiplicando lógica, datos y reglas que deberían mantenerse coherentes. El problema deja de ser únicamente cómo construir una aplicación y pasa a ser cómo construir capacidades que puedan ser utilizadas por diferentes aplicaciones sin que cada una tenga que conocer cómo están implementadas.

Cuando una aplicación crece, uno de los problemas que antes o después aparece no está necesariamente en la lógica de negocio ni en la cantidad de código, sino en la forma en que sus diferentes partes se comunican. Un componente necesita avisar a otro de que algo ha sucedido, ese segundo componente necesita informar a un tercero y, con el tiempo, una operación aparentemente sencilla termina recorriendo una cadena de llamadas entre módulos, servicios y sistemas. El problema no es que exista comunicación, sino que cada nueva dependencia directa hace que los componentes conozcan más cosas unos de otros y que cualquier cambio tenga un radio de impacto mayor.

Durante mucho tiempo, construir una aplicación significaba reunir buena parte de su funcionalidad en un único programa. Esa forma de organizar el software puede funcionar muy bien, especialmente cuando el sistema es pequeño o cuando el equipo necesita avanzar rápidamente. El problema aparece cuando la aplicación crece: cada nueva funcionalidad empieza a relacionarse con muchas otras, los cambios afectan a zonas que aparentemente no deberían estar conectadas y desplegar una pequeña modificación puede implicar poner en riesgo todo el sistema.

Una aplicación puede estar perfectamente programada y, sin embargo, representar mal el negocio para el que fue construida. Puede tener una arquitectura ordenada, pruebas automatizadas, una base de datos bien diseñada y un código limpio, pero utilizar conceptos que no coinciden con la realidad que sus usuarios necesitan gestionar. Cuando esto ocurre, el problema no suele encontrarse en una función concreta, sino en algo más profundo: el software y el negocio están utilizando modelos mentales diferentes para describir la misma realidad.