Un patrón se puede definir como el “mecanismo que nos permite enlazar una solución conocida y probada con un problema que se repite sistemáticamente. Y cada vez que se da el problema y se le aplica la solución, el problema se resuelve. Si a este par de problema-solución le agregamos una explicación y un ejemplo de cómo aplicar la solución al problema pues ya tenemos creado un patrón”.
Algunos de los muchos tipos de patrones que nos podemos encontrar:
- Patrones para la definición y diseño de Casos de Uso,
- Patrones para el modelado del Negocio,
- Patrones para flujos de trabajo,
- Patrones de diseño GRASP,
- Patrones de diseño de la banda de los cuatro. Orientados a objetos,
- Patrones de arquitectura,
- Patrones de integración,
- Patrones de diseño orientados a servicios.
Como aparece en el título de este post no me centraré en cualquier tipo de aplicación, si no en las “Aplicaciones Enterprise”, que se pueden definir como las aplicaciones que usan una arquitectura cliente/servidor con 3 o más capas arquitectónicas.
Entre las características de estas aplicaciones podemos listar las siguientes:
- Datos masivos (gran volumen) y persistentes,
- Acceso concurrente, lo que implica gran cantidad de usuarios,
- Variedad de interfaces de usuario, lo que implica diversidad en la funcionalidad brindada,
- Integración con otros sistemas, lo que implica que comparten funcionalidad y / o datos,
- Disonancia conceptual (modelo de datos con distintas visiones), debido a que poseen un modelo de negocio subyacente que abarca distintos aspectos de un área de negocio. Por lo tanto prestan distintas funcionalidades a distintos tipos de usuarios,
- Lógica de negocio, lo que implica procesamiento de datos.
- B2C ( comercio electrónico),
- sistemas financieros en línea,
- sistemas ERP ( Enterprise Resource Planning),
- ECM.
Estos tipos de sistemas ejemplificados todos comparten la estructura cliente/servidor y se estructuran en capas, por eso digo que estas son las dos características fundamentales para identificar “sistemas enterprise”.
Las capas más comunes son las siguientes:
- Capa de Presentación:
Esta es la capa que está de cara a los usuarios humanos, exponiendo UI. Para esta capa podemos usar patrones de presentación web como los de Martin Flowler. En esta capa se maneja la lógica de aplicación. - Capa de Servicios:
Esta es la capa que está de cara a los usuarios no humanos, otros sistemas, exponiendo APIs o servicios. En ella se resuelven los problemas del acceso a las funcionalidades de las aplicaciones a través de sus modelos de objetos y de la lógica de aplicación, o de proceso como me gusta decir, para diferenciarla de la lógica de negocio. Se pueden emplear los patrones de distribución de Martin Flowler. En esta capa se maneja tanto la lógica de aplicación como la lógica de negocio. - Capa de Dominio del Problema:
En esta capa se modelan los problemas de modelado del dominio y del negocio de la aplicación. Se pueden usar todos los patrones de diseño de la “GoF o Banda de los Cuatro”. Se enfoca fundamentalmente en el modelado del problema y la lógica de negocio. - Capa de Persistencia:
En esta capa se resuelven los problemas propios de la persistencia de los objetos en BD relacionales así como el acceso multiusuario a estos SGBD y las operaciones ACID y CRUD. Los patrones a utilizar aquí son disímiles casi todos los podemos ver en la documentación de Martin Flowler.
Dado el tipo de aplicaciones seleccionado, es decir del tipo Enterprise, donde las aplicaciones poseen un dominio complejo, con lógica de negocio compleja y muchas reglas de negocio, las cuales varían con el tiempo, y van modificando a las actuales, y nutriéndose con otras nuevas, la idea central es modelar el dominio utilizando programación orientada a objetos, obteniendo así un modelo del dominio, formado por objetos muy similares a la realidad, que se rigen según las reglas de negocio. Esto no es otra cosa que la Orientación a Objetos.
Para poder acompañar los cambios del negocio, actualizando así el modelo del dominio, se busca la manera de mantener este dominio lo más aislado posible del resto de la aplicación y me parece que esto último resume lo que aún no hemos podido interpretar e implementar:
¿Cómo desacoplar el dominio de negocio de nuestras aplicaciones del resto de los componentes de la aplicación de forma tal que los cambios en el dominio del negocio, dígase nuevas reglas, procesos, funcionalidades, puedan ser actualizadas en la aplicación sin tener que hacer un rediseño y re implementación completa de la misma? Vaya que me salió como un problema científico
La solución a este problema es el patrón “Capas” bien empleado, porque cuando se emplea mal no resuelve nada.
La solución más vista puede ser la siguiente:
Es la que casi siempre aparece en cada trabajo que vemos o proyecto que se desarrolla.
El problema con esta estructura es que mientras que en la capa de presentación se maneja la interacción con los usuarios humanos y en la capa de datos se maneja el acceso y persistencia de los datos, en la capa de modelo del dominio se manejan dos cosas que deberían estar separadas:
- Lógica y reglas del dominio. Lógica de Negocio.
- Lógica y reglas de la aplicación. Lógica de Procesos.
Digo que deben estar separadas porque es la única manera en que una aplicación podrá responder a los cambios del negocio de forma adecuada.
Entradas
Hola me gustaría saber que patrón debo usar si estoy haciendo uso de la arquitectura SOA?
ResponderEliminar