En la entrada anterior introducía este tema de patrones para aplicaciones Enterprise, y había dejado colgado un problema que considero bastante serio: el desacople que debe existir entre la lógica de proceso y la lógica de negocio, o entre la lógica de aplicación y la lógica de dominio, como lo quieran ver.
En esta entrada le damos continuidad al problema y proponemos una solución viable.
Elementos que buscamos:
- El modelo de dominio debe modelar el dominio general y poseer las reglas inherentes a este dominio. Esto debe permitir que pueda ser reutilizado en diferentes aplicaciones. Donde cada aplicación puede tener sus propias transacciones, operaciones, sobre este dominio de forma particular.
- Si la aplicación maneja diferentes formas de presentación: (web, desktop, mobile) la lógica de aplicación estaría en esta capa cliente, lo que no es bueno pues dificulta su mantenimiento.
Esta capa de servicio expone las funcionalidades, servicios, hacia la capa de presentación lo que permite hacer más “flacas” las implementaciones de la presentación las cuales solo tienen que preocuparse por los servicios expuestos y que pueden consumir. La capa de servicios tiene la responsabilidad de definir las interfaces a exponer, APIs o contratos de servicios, que determinan como puede ser usada y las funcionalidades a exponer.
Esta nueva capa nos permite un desacople enorme, ya que la capa de presentación no tiene que estar “pegada” al resto de la aplicación, puede encontrarse en un lugar remoto y solo preocuparse por invocar a los servicios expuestos en la capa de servicios.
Y es que si se diseña bien se tendrá esta capa de servicios, y cada servicio podrá ser expuesto como un servicio web/restful y ya podrá formar parte del proceso de integración. De lo contrario habrá que acceder directamente a su BD saltándonos reglas de negocio y funcionalidades para poder al menos integrar algo.
Seguimos:
Es importante entender que en la capa del modelo del dominio va lo común a un dominio determinado y que es independiente de una aplicación en particular, por lo que puede ser reutilizado por varias.
Es en la capa de servicios donde irá la lógica de aplicación o de procesos específica para aplicaciones además de que a través de esta capa también es recomendable exponer las funcionalidades comunes de la capa de modelo del dominio.
Hasta este momento casi que hemos resuelto todos los problemas que se nos pueden presentar con esta estructura en capas, pero queda uno aun fundamental, y es que la capa de modelo del dominio aun conoce demasiado de la capa de datos. Lo cual atenta contra el bajo acoplamiento que siempre queremos buscar.
La solución nuevamente es crear una indirección a través de otra capa: la capa de persistencia.
Esta capa nos permite evitar que el modelo de dominio conozca de la estructura de las BD o de la manera en que los datos se guardan, se persisten y donde es que se guardan. Esto es así porque el problema tecnológico de los datos no tiene nada que ver con la lógica del dominio. Por eso esta capa de persistencia asume toda esta responsabilidad para desacoplarla.
Al final nos quedará lo siguiente:
Como ven todo queda bien claro ahora y las ventajas saltan a la vista:
La separación de responsabilidades es enorme, lo cual siempre es bueno.
- El desacoplamiento se mantiene en cada momento.
- La reutilización se potencia por todos lados.
- Podemos usar diferentes formas de presentación.
- Estamos independizados de la forma y del mecanismo de persistencia.
- Podemos distribuir las funcionalidades buscando alto rendimiento y escalabilidad de las soluciones. Este tipo de distribución se puede hacer en capas físicas (tiers) que a veces se confunden con las capas lógicas (layers).
- Las reglas y la lógica del dominio se separan de las reglas y lógicas específicas de las aplicaciones.
En estos casos una forma de despliegue típico es la siguiente:
Interesante verdad?
Entradas
Patrones de Diseño de Arquitecturas de Software Enterprise. II