¿Cómo representar contextos acotados?

Question

Me refiero - física, en el código. Organización de los nombres, espacios de nombres, carpetas, asambleas, la base de datos / s.

¿Cómo contextos delimitadas deben interactuar?

Por ejemplo, no dude en utilizar clásico e-commerce dominio de negocio .

Answer 1

Yo diría que 'depende'

Algunas veces puede ser suficiente para mapear sus entidades BC a la misma base de datos y, a veces es posible que tenga diferentes bases de datos para su AC.

OMI, el comercio electrónico podría ser más de un AC de un dominio completo.

he pasado un poco demasiado tiempo en un agente de ventas entera donde se vendían productos alimenticios.

Así que el dominio era "todo venta" y los contextos acotados era, inventario, compra, ventas, facturación, catálogo de productos y el comercio electrónico (tal vez utilizan la redacción Inglés mal aquí)

Cada uno de éstos antes de Cristo conocía de "productos", pero todos ellos tenían su punto de vista diferente de un producto.

por ejemplo. Compra puede tener una entidad de producto con información de proveedores, precio de compra, etc que se le atribuye.

Mientras que un producto en el dominio del comercio electrónico seguirá el modelo desde el punto de vista del cliente, sería contar con información relevante para el cliente que las opiniones que, a su precio específico, etc.

el comercio electrónico aC obtendría información sobre sus productos a partir de múltiples fuentes; catálogo de productos y ventas. donde la información es la base de los precios de catálogo de productos específicos y de los clientes son de ventas.

Así que el repositorio del producto en el comercio electrónico antes de Cristo podría hacer contexto de mapeo de la otra antes de Cristo de (a través de los servicios de algún tipo, lo más probable web o WCF en mi caso) para construir nuestra entidad producto de comercio electrónico)

En lo personal yo modelar esto como conjuntos separados, me gustaría tener un comercio electrónico modelo y un modelo de ventas.

La mayor parte de la información en mi modelo de comercio electrónico podría provenir de fuentes externas y no sería localmente persistentes. Sólo cosas como carro de la compra sería persistente localmente ya que esos objetos son propiedad del modelo de comercio electrónico.

Una vez que un cliente intentos para completar su compra, yo construiría un pre-pedido del carrito de la compra y luego pasar a la AC que las ventas. Ya sea por una llamada de servicio directa o por medio de una cola de mensajes.

Así que en resumen, que tienden a construir mis sistemas en torno a una específica antes de Cristo y sólo interactúan con otros aC a través de servicios de.

Yo sé que un montón de gente puso sus chalecos en las mismas asambleas y el uso múltiple de AC desde la misma aplicación, etc. Pero me resulta extraño por qué una aplicación para un propósito específico debe saber sobre múltiples contextos. Prefiero hacer que sabe de un solo contexto y luego pasar cualquier dato que necesito a otras aplicaciones.

Answer 2

luego estoy de acuerdo que todo depende, pero hay algunas pautas que pueden / deben seguirse. El propósito de contextos acotadas es, así, los límites. Los límites que separan en parte de la solicitud de otro mediante la introducción de un contrato bien definido (interfaz).

tiendo a BC tratan como servicios en SOA. Para mí significa lo ideal es que están físicamente separadas aplicaciones (procesos OS / IIS sitios web). Los binarios también se separan por supuesto. Toda la comunicación entre los BC es idealmente asíncrona. En el mundo real, es casi imposible, pero al menos no permiten transacciones a través de BC porque son pura maldad.

Espero que ayude.