Parte, montón y totalidad
La pregunta de cuándo un conjunto de partes constituye un todo y cuándo permanece montón atraviesa tanto la economía política como la arquitectura de software. Una lista enumera componentes; todavía no explica la unidad que los hace actuar como un sistema.
El número de piezas no resuelve el problema. Dos partes pueden formar una unidad rigurosa y mil partes pueden seguir yuxtapuestas. Lo decisivo es si existe una relación que determine la función de cada componente y reproduzca la forma común cuando el sistema cambia.
Una relación que también transforma
Una totalidad no es una caja colocada alrededor de elementos ya terminados. La pertenencia modifica a las partes. Un nodo dentro de una red de responsabilidad no es el mismo objeto que ese nodo aislado: adquiere permisos, límites, obligaciones y dependencias que solo existen por la relación.
Esto permite una prueba práctica. Si se retira una pieza y el resto conserva la misma forma, probablemente se retiró un componente reemplazable. Si se elimina la relación que asigna funciones y ya no es posible decidir qué cuenta como operación válida, se ha tocado la estructura constitutiva.
Diseñar la unidad
En software es común dibujar primero los módulos y conectar después las flechas. Pero las flechas suelen contener lo más importante: contratos, autoridad, estados permitidos y condiciones de fallo. Diseñar un sistema exige tratar esas relaciones como objetos de primera clase.
La unidad no se declara en el nombre del proyecto. Se demuestra en la capacidad del conjunto para conservar sus reglas, explicar sus transformaciones y responder por sus resultados.