Al igual que hoy, la semana pasada escribí sobre un patrón arquitectónico, transacción script, esta semana voy a comentar el patrón Domain model.
Este patrón, tiene como meta fundamental expresar el negocio a ser sostenido en términos de objetos, estos objetos tienen comportamiento y su interacción depende de los mensajes que se comunican entre ellos, es el patrón orientado a objetos por excelencia y hace que los objetos modelados estén en concordancia con el negocio, se hablé un lenguaje común con el cliente y se pueda expresar en forma más sencilla como interactúan los objetos en el flujo de negocio generar. Lo negativo de este patrón es que es muy costoso de implementar en términos conceptuales, el modelo de negocios debe estar mejor definido para que se refleje en el modelo conceptual que se forma, pese a esto último es más sencillo de modificar y alterar una vez en desarrollo que el patrón transaction script. Algunos errores que de cometen al tratar de implementarlo es modelar sólo objetos que serán persistidos como parte del modelo de dominio, un negocio no sólo consta de partes que se guardan si no además hay objetos que y procesos que pueden ser modelados y no necesariamente ser guardados en la base de datos, los fanáticos de este modelo lo utilizan siempre, aunque en situaciones donde el negocio es simple y con un flujo sin tanta decisión puede volverse muy engorroso de implementar.