Re: Integrating BCs - in real life

Hi Atle

A third alternative might be to limit the communication between BCs to messages (or events if you will), such that you do not need to query data from other BCs. In this type of architecture, each BC (service in SOA terms), holds only the data attributes (and logic) which concerns the BC. Now, if BC2 needs to act upon something that happened in BC1, BC1 publishes a message and BC2 subscribes to it and performs any logic required. When this happens, eventual consistency is usually sufficient. If a transactional consistency is required across BCs, than in most cases, that means that the context boundaries should be tuned.

Does this help?

Moran

--- In [email protected], "atle03" <atleh3@...> wrote:
>
> Hi all,
> 
> If one application service in one bounded context (BC) needs to access the domain models for several BCs, how will this look like in the runtime environment?
> 
> I see two alternatives:
> 
> 1. The various BCs are hosted/deployed separately. In this case, operations on "remote" domain models could be accessed through (web) services or similar. A side effect is that transactions cannot span such remote operations, and that domain operations must be wrapped in a service layer. Web service hell?
> 
> 2. The various referred domain models are deployed with the BC that refers to them. This means that calls are in-process. BUT this also means that the "host " BC must hold connection strings and optionally other config for all the domain models (repositories) it uses. Config hell?
> 
> Both options seem to have large drawbacks to me. Is there something I have missed?
> 
> Atle
>



------------------------------------