El primer capítulo da el tono: si algo fuera siempre la mejor opción, ya estaría automatizado y nadie necesitaría arquitectos. Lo que queda es el análisis de concesiones, y el libro lo enseña sobre los problemas que no tienen respuesta bonita: cuándo partir un sistema, cómo repartir los datos, qué hacer cuando una operación toca varios servicios y ya no hay una transacción que la sostenga.
Qué saqué de él
Las fuerzas que empujan a partir y las que empujan a mantener junto, con nombre propio cada una. Tener ambas listas cambia la conversación: en lugar de discutir si conviene separar un módulo, se revisan una por una y se ve cuál pesa más en este caso. La respuesta a veces es no separar nada, y eso también es una decisión de arquitectura.
Los datos como el problema real. Partir el código es la parte fácil; lo difícil es decidir quién es dueño de cada dato y qué pasa cuando dos partes lo necesitan a la vez. Desde entonces, antes de proponer cualquier integración, dibujo primero dónde nace el dato y quién tiene derecho a cambiarlo.
Y la disciplina de escribir la decisión con su costo: qué se gana, qué se pierde y bajo qué condición habría que revisarla. Una decisión sin su reverso escrito es una opinión con fecha.
Qué dejé fuera
Mucho. El libro razona sobre servicios distribuidos a una escala que una empresa mediana no va a tener nunca; los capítulos de flujos distribuidos y contratos resuelven problemas que aparecen con decenas de servicios. Y el relato ficticio que hilvana el libro, con su equipo de soporte y sus reuniones inventadas, ocupa un espacio considerable. A mí me estorbó; conozco a quien dice que gracias a eso lo terminó. Aquí está la parte de esto que entrego.