Arquitectura de software ¿Modelo Canónico Patrón o AntiPatrón?
Te explicaré en qué consiste como patrón y cuando podría verse como un antipatrón.
El modelo de datos que se debe construir para que varios sistemas interactúen entre sí se llama modelo canónico, que no es más sino la búsqueda de la homogeneidad de los nombres utilizados en el compendio de la integración. Así el modelo integrado de las diversas fuentes les hace sentido a todos en un mundo ampliado como lo fue la integración con otros sistemas.
Al diseñar el modelo de integración orientado a los datos es decir el llamado “Modelo canónico” debemos tener en cuenta que nuestro diseño cumpla con las siguientes propiedades:
- Neutralidad. Nuestro modelo canónico por lo general se crea en capas medias de integración por lo tanto no debe estar acoplado estrechamente a alguno de los sistemas integrados sino por el contrario intentar ser neutral pero que siga haciendo sentido del significado general del dato de negocio.
- Estandarización. Debemos observar y crear un formato de datos que sea consistente y sirva para agrupar los tipos de datos de las integraciones.
- Reusabilidad. Nuestro formato de datos y diseño de negocio para converger con otros sistemas debe ser lo suficientemente estándar para ser reutilizado en el negocio.
(Nota: En esta última característica es donde el patrón de arquitectura modelo canónico pretende hacer un estandar de reusabilidad que podría convertirse en un antipatrón. A continuación te explicaré por qué)
“No es el mismo concepto de persona para el departamento de marketing y soporte de una compañía de seguros. Un vuelo para un sistema de gestión del tráfico aéreo tiene un significado diferente dependiendo de si fue ocupado por un piloto o si es un vuelo en curso en la parte superior de su espacio aéreo. Una pieza PLM tiene una representación completamente diferente dependiendo de si acaba de ser diseñada o si debe ser mantenida por un equipo de soporte.”
https://teivah.medium.com/why-is-a-canonical-data-model-an-anti-pattern-441b5c4cbff8
Así querer tener un estandar de todo el negocio podría llevarnos a problemas pues para poner otro ejemplo un “usuario” para el departamento de afiliaciones es diferente a un “usuario” para el departamento de TI. Aquí es donde aparece DDD (Domain Driven Design) que nos sugiere tener un modelo de datos canónico pero dividido en contextos o dominios de negocio para acotar así el alcance de cada modelo canónico a cada parte del negocio en vez de un estandar estrechamente especializado. A esto se le conoce como “Bounded context” contextos delimitados.
Si quieres escuchar un poco las de DDD visita este enlace.
Estos contextos delimitados hacen referencia al mismo tema de modelo canónico pero orientado a un mundo más pequeño donde si pueda cumplir con un lenguaje común para un determinado dominio. Los dominios los podemos asemejar a áreas de un negocio como el anteriormente mencionado: Afiliaciones y TI. Así al delimitar los contextos de nuestro modelo canónico podremos tener un lenguaje común entre nuestros dominios y facilitar la integración con otros sistemas, este lenguaje común se conoce como “Ubiquitous language” lenguaje ubicuo.
En resúmen podemos concluir que un patrón de arquitectura solo es aplicable en determinados contextos y que cada patrón pudiese convertirse en un antipatrón según el caso de uso. Por lo tanto se hace totalmente necesario que conozcamos ampliamente el negocio y su contexto antes de aplicar patrones de arquitectura deliberadamente.
Palabras Clave ejemplo DDD, patrón, antipatrón, modelamiento de software.
Si quieres más información de estos temas escribeme a david.castano@pragma.com.co
Links relacionados a lo que te hablo.
Modelo canónico
¿Podría ser el modelo canónico un antipatrón?
https://teivah.medium.com/why-is-a-canonical-data-model-an-anti-pattern-441b5c4cbff8
Bounded context — Contextos delimitados
https://medium.com/@umitulkemyildirim/what-is-bounded-context-de4942079cc4
