RE: Integrating BCs - in real life
Mauro Servienti <[email protected]>
| Newsgroups | gmane.comp.programming.domain-driven-design |
|---|---|
| Message-ID | <0D71C042265E7B4D871B59569C7774D751A0F990@AMXPRD0310MB390.eurprd03.prod.outlook.com> |
but...the main concern is: is it possible that a BC issues a command for another BC? or the other BC reacts to an event occured in the firtst one? In the real world: - is the "order delivey system" that tells to the accounting system to invoice order "123" becuase it is delivered? - or the order delivery system simply broadcasts to the outside world the the order "123" has been delivered and one of the listener is the accounting system? In the second scenario, that is much more interesting, you cannot at all relay on distributed transactions because hmaybe there are a lot of systems interested in that event and the source system simply cannot handle a trnsaction with each one. and each time there is a new guy interested in the event you need to change the source system to explain that there is new listener to deal with: a coupling hell :-) .m ________________________________________ From: [email protected] [[email protected]] on behalf of atle03 [[email protected]] Sent: Monday, April 22, 2013 22:00 To: [email protected] Subject: [domaindrivendesign] Integrating BCs - in real life 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 ------------------------------------ Yahoo! Groups Links ------------------------------------