Los autores construyen una aplicación pequeña y le van agregando estructura: separan el modelo del negocio de la base de datos, meten una capa de servicio, definen unidades de trabajo, agrupan objetos en agregados con una frontera de consistencia y terminan con eventos y un bus de mensajes. Cada patrón viene con su justificación y, lo que agradezco, con su costo.
Qué me llevé
El agregado y su frontera de consistencia es lo que más uso, y no para programar sino para diseñar. La pregunta de qué cosas tienen que cambiar juntas o no cambiar en absoluto es la que ordena un modelo de datos: un pedido con sus líneas cambia junto; un pedido y el saldo del cliente no tienen por qué. Cuando una empresa reporta datos inconsistentes, casi siempre alguien dibujó esa frontera en el lugar equivocado.
La segunda: la capa de servicio como lugar donde vive la regla de negocio, lejos de la pantalla y lejos de la base. En un ERP la tentación es poner la lógica en el botón, y esa lógica se vuelve invisible el día que alguien crea el mismo registro desde una importación o desde una interfaz.
Y la tercera, que los autores dicen con honestidad: cada patrón agrega indirecciones. Si el equipo es una persona y el sistema es pequeño, la mitad no vale la pena.
Qué dejé fuera
Buena parte, por una razón concreta: trabajar dentro de un ERP no es trabajar con las manos libres. El marco ya trae su propio acceso a datos, su propia unidad de trabajo y sus propias convenciones, y pelearse con él para imponer una arquitectura hexagonal produce código que ningún consultor posterior va a entender. Lo que me llevo son las preguntas; la implementación literal, no.