¿Asesoramiento para diseñar sistemas completos acoplados libremente?

Question

¿Cómo diseña un sistema de acoplamiento flexible que a menudo requiere datos entre sí pero que no necesariamente pertenecen a la misma categoría?

Por ejemplo, llevemos el viejo ejemplo de Pet-shop un paso más allá y creemos una franquicia de tienda de mascotas. Cada tienda de mascotas tiene su propio sitio web con su información de contacto, promociones y existencias actuales.

Los propietarios de franquicias desean tener una lista de todas las tiendas de mascotas franquiciadas junto con información de contacto y posiblemente algunas fotos disponibles en su sitio corporativo. Quieren poder actualizar esta información y que las actualizaciones se envíen automáticamente en ambos sentidos. También quieren proporcionar la información de promociones a los sitios de todas las tiendas de forma automática.

Por lo tanto, en este caso, las listas de valores son de "propiedad" por las tiendas, y la información de contacto es de propiedad parcial por ambas entidades, y la información de la promoción es "propiedad" por HQ. Debido a razones arbitrarias, todos estos datos no pueden almacenarse en el mismo lugar.

¿Existen algunas prácticas recomendadas o estrategias comunes para hacer frente a una situación como esta?

Answer 1

He estado pensando en ese problema, y ??lo expreso diciendo que las relaciones entre clases están determinadas contextualmente. Y cualquier modelo que asuma asociaciones estáticas globales (acoplamiento inherente) entre clases es problemático.

Otro ejemplo que me gusta usar es Productos.

Un producto puede jugar un montón de roles diferentes. Está asociado con un artículo de pedido, que está asociado con un pedido, que está asociado con un cliente.

Lo proporciona un vendedor.

Está en un catálogo, tal vez por sección y página.

Es responsabilidad de un Comprador, con disponibilidad de múltiples proveedores.

La capacidad de manejar esta complejidad fácilmente es el beneficio fundamental del modelo de datos relacionales; y no lo he visto bien tratado en términos de POO.

Aparte: hay otro ORM (modelado de roles de objetos, ver VisioModeler, InfoModeler, etc.) que analiza la pregunta desde el lado relacional, bastante útil (en mi humilde opinión).

Cuando se aísla de la relación de la base de datos (mediante el uso de generadores CRUD, ActiveRecords, etc.) está ocultando este aspecto importante. (Creo que LINQ tiene el mismo problema, además de presentar problemas fundamentales de acoplamiento, pero aún no lo he resuelto por completo).

Creo que puede abrirse camino con éxito si tiene cuidado, pero se vuelve fácil incrustar el acoplamiento en el diseño, especialmente si trabaja desde la base de datos hasta el resto de la aplicación, en lugar de la otra dirección .

Answer 2

Entiendo que este tipo de problema se aborda con mayor frecuencia utilizando una técnica llamada "federación de datos". - las entidades independientes funcionan de manera independiente, pero existe una entidad tipo paraguas que proporciona la capacidad de mirar el sistema como un todo.

Aquí hay un artículo que puede ser útil: http://www.soamag.com/I22/0908-1.asp

Al planificar su arquitectura, tenga en cuenta lo que sucede cuando uno de los participantes no está disponible. Por ejemplo, recomendaría que la información de la promoción se repita en todas las tiendas, ya sea como un proceso por lotes o cuando cambien los datos de referencia. De esa forma, si la red se cae, las tiendas individuales aún tienen información de promoción y pueden funcionar.

Answer 3

Parece que SOA puede ser útil en este caso. Me refiero específicamente a SOA de nivel empresarial como se describe, p. Bill Poole y Udi Dahan con implementación basada en eventos async pub-sub.

Usted describió varias funciones comerciales con propietarios separados: Franquicias y Ventas. Desea lograr un acoplamiento flojo entre ellos.

En SOA, define el servicio de franquicias y varias instancias de servicios de ventas, una para cada tienda. Las tiendas son inicialmente muy similares, pero pueden evolucionar por separado.

Luego, define los eventos comerciales de interés mutuo que se producen en estos servicios. El servicio de franquicias puede publicar el evento NewPromotion al que se suscriben todos los servicios de ventas. Este mensaje de evento contiene todos los detalles sobre la promoción, y los consumidores eligen lo que necesitan. El servicio de ventas a su vez publica el evento ContactDetailsChanged para ser consumido por Franchising.

Cada servicio tiene su propia implementación de múltiples niveles en el interior, completa con base de datos, sitio web orientado al cliente, puntos de integración privada con otros sistemas, etc.

Cada servicio almacena de forma privada todos los datos que le interesan: listas de existencias, información de contacto, información de promoción, en la forma que considere adecuada. Las actualizaciones de la información en un servicio se propagan a otros servicios a través de eventos.

En el lado de la implementación, necesita algún tipo de bus de servicio entre servicios, con soporte para mensajes duraderos a través de Internet poco confiable, p. NServiceBus . No se necesitan servicios web (tm).

Sus servicios se acoplan libremente en la implementación, porque solo comparten contratos (descripción de mensajes y puntos finales que publican) y pueden desarrollar representaciones internas de forma independiente. También están poco acoplados en el tiempo, porque si en ningún momento se envían entre sí solicitudes síncronas que pueden expirar por Internet. Todos los mensajes son manejados por la infraestructura (bus de servicio).

Espero que esto ayude :)

Answer 4

Estoy mayormente de acuerdo con la solución propuesta anteriormente (usando SOA). ESB podría ser un buen enfoque dependiendo de la complejidad de la aplicación. Pero, creo que ESB tiene una gran huella y trae una complejidad innecesaria para la mayoría de las aplicaciones del mundo real.

Pero, en mi humilde opinión, cualquier buena arquitectura debe ser fácilmente adaptable a los servidores de aplicaciones sin grandes cambios de arquitectura / diseño.

Suponiendo una aplicación de n niveles de mediana y gran escala basada en Java, estas son mis sugerencias para el nivel medio y el nivel EIS:

1. Separe cada una de las implementaciones del subsistema y exponga su funcionalidad a través de una interfaz de servicio y oculte las implementaciones directamente utilizadas o referenciadas.

2. Cree un archivo JAR (o EAR) para cada uno de los subsistemas y determine las dependencias de tiempo de ejecución y tiempo de compilación entre los subsistemas / JAR identificados anteriormente.

3. Invierta una buena cantidad de tiempo en determinar la granularidad correcta de los métodos de interfaz de servicio y las dependencias del subsistema.

4. Durante este esfuerzo, intente identificar la capa DAO (suponiendo que esté involucrada una base de datos) para cada uno de los módulos y separe las tablas de la base de datos para cada uno de los subsistemas.

Para el nivel web, intente hacer lo mismo que arriba dividiendo la capa de presentación por subsistemas. Cree un archivo WAR por cada uno de los subsistemas. Intente colocar la capa de presentación WAR en el archivo EAR apropiado identificado anteriormente, si es necesario.

Una buena validación de esta arquitectura anterior es implementar esto en OSGi utilizando cada uno de los servicios como servicio OSGi (después de crear los archivos de manifiesto apropiados).

Tenga en cuenta que la comunicación asíncrona o basada en eventos también se puede configurar entre cualquiera de estos subsistemas, si es necesario.

Esto brinda la oportunidad de dividir los subsistemas e implementarlos en diferentes granjas de servidores para obtener mejores oportunidades de escalabilidad.

¡Buena suerte!