El libro recorre el ciclo completo: diseñar una interfaz con su especificación antes de programarla, probarla por capas, ponerla detrás de una puerta de enlace, protegerla, y hacerla evolucionar sin romper a quien ya la usa. Está escrito con un caso que atraviesa todo el texto y con decisiones documentadas al final de cada tramo.
Qué saqué de él
La primera costumbre son los registros de decisión. Cada elección de arquitectura se anota con tres cosas: el contexto en el que se tomó, la opción elegida y lo que se acepta a cambio. Ocupa media página y resuelve la pregunta que llega meses después, cuando alguien quiere saber por qué está hecho así, y la respuesta honesta ya no se acuerda nadie. Desde que las escribo, entrego esas notas junto con el mapa.
La segunda son las pruebas de contrato. Es la idea que más me cambió el trabajo con integraciones: en lugar de probar el sistema entero de punta a punta, se escribe qué espera exactamente quien consume y se verifica contra quien provee. Cuando el otro equipo cambia un campo, se entera una prueba y no el usuario, y esa diferencia es lo que separa una integración que se puede mantener de una que hay que vigilar a mano.
La tercera idea es dónde poner lo que es común. Autenticación, límites de uso y registro van en la puerta de enlace, no repartidos por cada servicio. Cuando esas cosas están dispersas, cambiar una regla obliga a tocar diez lugares y siempre queda uno sin tocar.
Qué dejé fuera
La malla de servicios y buena parte de las decisiones de plataforma. El libro supone un equipo y una infraestructura propia; quien trabaja solo, contra un ERP que ya publica su propia interfaz, se encuentra con que la mitad de esas decisiones vienen tomadas de fábrica. Tampoco me llevé el entusiasmo por descomponer sistemas en servicios: casi siempre se propone antes de haber entendido el dominio.