Una lista de posibilidades no es todavía un producto. El producto aparece cuando puede explicar qué responsabilidad asume, cuál no y qué condición justificaría revisar ese límite.
Cada sí crea una obligación.
Una nueva función introduce estados, errores, permisos, soporte y continuidad. Su coste real no es el tiempo necesario para dibujarla o programarla, sino el tiempo durante el que el producto deberá responder por ella.
Por eso priorizar no consiste solo en ordenar una lista. Consiste en decidir qué relación con la operación merece convertirse en parte permanente del sistema.
Un límite claro protege al producto de prometer más de lo que puede comprender.
Los límites pueden cambiar sin desaparecer.
Una arquitectura útil no congela la primera definición. Hace explícitas sus fronteras para que una expansión futura ocurra mediante una decisión visible, no por acumulación accidental.
La escalabilidad más importante no es aceptar más tráfico. Es poder cambiar de responsabilidad sin volver incomprensible el sistema.
Para decidir
Construir desde la base significa saber qué sostiene el sistema y también dónde termina su responsabilidad actual.