Arquitectura de un sistema empresarial prototipo

En las entradas anteriores establecimos que la gran mayoría del software empresarial se parece entre sí, y entre otros ámbitos de negocio semejantes. Lo que es diferente es la variabilidad de las características que se implementan, cuales son y de qué forma son implementadas.

Vamos a hacer un pequeño acercamiento a la arquitectura de un sistema empresarial prototipo básico. Se muestra un diagrama de bloques de dicho prototipo:

Nota: Debido a que este artículo se creó originalmente como parte del desarrollo de generador “CapicuaGen”, existe varias partes que hacen referencia a dicho generador llamadas “Posibles uso del generador en este contexto”, las cuales se encuentran en cursiva. Si no se está creando un generador de código, o si no es de interés, la parte relativa a “CapicuaGen”, se puede omitir.

Interfaz de usuario

En esta capa se define la apariencia y la interacción con nuestros usuarios y clientes, debe ser lo suficientemente sencilla para que la usen con facilidad, y lo suficientemente completa para que se sea útil. Posibles interfaces son:

Interfaces tradicionales para monitor (computadora)

• Interfaz de escritorio: Puede ser para un sistema de escritorio para Windows, Linux, Mac u otros.
• Interfaz web: Un sitio web tradicional. Aunque HTML y CSS nos garantiza homogeneidad entre los distintos navegadores, ocasionalmente hay pequeñas diferencias de visualizado, que tenemos que tener en cuenta al momento de desarrollar.

Interfaces móviles

• Aplicaciones: Son las aplicaciones nativas desarrolladas para cada dispositivo móvil. En este escenario tenemos que consideran distintas resoluciones de pantalla y tipos de dispositivo como tablet, o smart phones. Podemos desarrollar aplicaciones para Android, iOS y Windows entre otros.
• Interfaz móvil web: Es una interfaz Web diseñada explícitamente para dispositivos móviles (considerando el tamaño de su pantalla).

Posibles uso del generador en este contexto

La interfaz representa lo que puede "hacer" y puede "ver" nuestro usuario, y esto debería ser común para todas las plataformas, el generador debiera ser capaz de crear dicha funcionalidad, y una vez que cambie el negocio, rehacer el código automáticamente para que se adapten todas las interfaces a dichos cambios. Sería necesario contar con una característica generadora para cada plataforma deseada.

Interfaz de servicios

Representa la puerta de acceso a la funcionalidad del negocio. Es una fachada que expone la funcionalidad de forma que la pueda consumir apropiadamente la interfaz gráfica. De esta manera aislamos el negocio, de la forma en la que este es expuesto.

Por ejemplo puede exponerse el negocio de las siguientes formas (entre otras):

• Componentes
• Web Services
• Socket
• RPC
• HTTP

Posibles uso del generador en este contexto

Debido que es un mismo negocio el que se debe exponer y que solo cambia la forma de exponerse, el generador puede crear automáticamente cada fachada necesaria en base a dicho negocio.

Negocio

En esta capa está el problema que queremos resolver en nuestro sistema, representa, en forma de software, la solución a una necesidad a cumplir por la empresa con respecto al mercado.

En esta capa puede haber diversos elementos y diferentes enfoques de resolución, podríamos distinguir los siguientes elementos:

• Entidades de negocio: Son elementos que representan al modelo del negocio, la representación debe ser tanto de información (datos), como de comportamiento, aislar los datos del comportamiento, nos llevaría a un modelo de dominio anémico. [1]
• Flujos de operación: Son elementos que representan que entidades de negocio están vigentes y la forma en la que se convierten en otras. Pueden representar flujos de trabajo que no tengan una correspondencia en una entidad de negocio.
• Acceso a otros componentes: Representan el punto de entrada a componentes ajenos a nuestro software, pueden ser componentes empresariales o componentes externos a nuestra empresa, en cualquier caso esta funcionalidad está aislada, de forma que otros componentes de negocio u otra capa, ignoran el acceso a componentes externos.

Posibles uso del generador en este contexto

Esta parte es muy dependiente de como diseñemos el modelo del dominio de nuestra aplicación, en base a esto podemos crear elementos como:

• Entidades de negocio en base a otros elementos como un UML, o una base de datos.
• Agregar funcionalidad en base a diversas configuraciones.
• Agregar funcionalidad y comportamiento común de la empresa.

Persistencia

Esta capa se encarga gestionar el acceso a diversas fuentes de persistencia, desde donde obtener y guardar la información de nuestro sistema.

Interfaz de persistencia

Expone las funcionalidades de persistencia abstrayendo al negocio de conocer los detalles sobre la tecnología encargada de esta.

Posibles uso del generador en este contexto

Es posible crear las interfaces de los servicios de persistencia, siguiendo algún patrón de software o algo política empresarial sobre cómo deben persistirse los elementos de negocio.

Proveedores de Información

Son los mecanismos concretos por los que se persiste la información. Gracias a la interfaz de persistencia dichos mecanismo podrían ser cambiados por otros, sin afectar al negocio. Algunos de estos mecanismos son:

• ORM.
• Stored Procedures.
• Sentencias SQL.
• XML.
• Archivos de texto.
• Servicios RESTFul.

Posibles uso del generador en este contexto

La persistencia es una de las grandes oportunidades para los generadores de código [2]. Dependiendo de nuestro diseño puede convertir los modelos, en tablas y crear los puntos de acceso para dichas tablas, ya sea por SQL, Stored, o tecnologías ORM. Por otro lado si nuestro diseño comienza por la creación las tablas y procedimientos almacenados (cosa que en principio no es recomendable), se puede crear el acceso a la base de datos, y el modelo a través de ella.

Abstracción del acceso a datos

Mientras la capa anterior trabaja sobre la tecnología de persistencia, esta capa proporciona acceso a dicha tecnología, sin preocuparse donde esté ubicada “físicamente” dicha tecnología. Por ejemplo si el destino es un documento XML, dicho documento puede guardarse en un archivo, en una base de datos, o en cualquier otro tipo de repositorio. Si el destino fuera una base de datos, esta podría ser SQL Server, Informix, MySQL, SQLite, o cualquier otro. Esta capa sabría cómo comunicarse con cada uno de estos proveedores, con independencia de la capa anterior. Igualmente esta capa se encargaría de cualquier tipo de la configuración sobre conexiones y localización de archivos, acorde a las políticas de la empresa acerca del almacén y la seguridad de esta información.

Posibles uso del generador en este contexto

El generador puede ayudarnos a crear el código necesario para el acceso a los repositorios de información, y además puede generar distintos accesos, para simular diversos esquemas de persistencia en un ambiente de pruebas o de desarrollo.

Seguridad

Es una capa que afecta a todas las demás independientemente de lo profundas o externas que sean [3]. Los servicios que ofrecen la capa de seguridad son (entre otros):

• Autentificación: Garantiza que la persona que está usando el software es quien realmente está identificada ante el sistema.
• Autorización: Asegura que la persona autenticada, solo pueda realizar las tareas sobre las que tenga autorización.

Posibles uso del generador en este contexto

El generador puede crear distintos tipos de seguridad y agregarla en los puntos requeridos ya sea por programación orientada a aspectos, o cualquier otro mecanismo.

Políticas empresariales

Implica cualquier aspecto empresarial, que se pueda aplicar de forma vertical en cualquier punto de nuestro sistema. Pueden ser, entre otro:

• Reglas empresariales que deben cumplir todos los sistemas.
• Mecanismos de Cache
• Mecanismos y política de bitácoras y trazabilidad
• Inyección de código
• Gestión de dependencias
• Validación de datos
• Control de excepciones

Posibles uso del generador en este contexto

Dependiendo de qué tipo sea la política empresarial, el generador de código, puede ayudarnos a introducirlas en los lugares adecuados de nuestro software, y encargase de “replicarlas” en el caso que estas cambien.

Acerca de las arquitecturas empresariales

Si bien lo mostrado anteriormente es un ejemplo de una arquitectura empresarial prototipo, hay que tener en cuenta que debemos usar la arquitectura adecuada para resolver cada problema en concreto. No existe una arquitectura que sea indicada para resolver todas los necesidades de software a los que se enfrenta un empresa.

Para considerar una arquitectura software adecuada, esta debe cumplir lo siguiente:

• Que resuelva la necesidad de negocio de forma adecuada.
• Que sea sencilla de entender y de explicar.
• Que sea mantenible.

---

[1] El modelo de dominio anémico, es un antipatrón de diseño, en que se usa un modelo del dominio, sin lógica de negocio, lo cual rompe el paradigma de la orientación a objetos donde dichos elementos (información y comportamiento) van juntos en una misma entidad.

[2] Jack Herrington, expresa en su libro “Code Generation in Action”, que el principal motivo por el cual comenzara a usar generación automática de código, son las experiencias y dificultades que tuvo trabajando con capas de acceso a datos, como menciona el capítulo 6: “Teaching engineers how to use code generation for database work is my primary reason for writing this book. This motivation comes from some personal experiences with database work.”

[3] Principio “Defense in Deep”