RE: Integrating BCs - in real life
Mauro Servienti <[email protected]>
| Newsgroups | gmane.comp.programming.domain-driven-design |
|---|---|
| Message-ID | <0D71C042265E7B4D871B59569C7774D751A0F958@AMXPRD0310MB390.eurprd03.prod.outlook.com> |
for me transactions in a distributed environment are pure evil :-) one BC internally in its relation with its own resources can be (must be?) transactional, with its own resources. Spanning transactions across BC increases lifecycle coupling: all involved BCs must be up & running and must understand the same distributed transaction language, in a 2 phase commit if one of the partecipants looses connection to the coordinator really amazing strange things can happen :-) I tend to resolve BC (even when in the same process) communication using messages and a bus in this way I gain lifecycle decoupling and delivery guarantees, I know that sometime in the near future the other BC will be in the state I expect it to be, in the near future. Transactions involve the concepts of "now" and "always" but distributed environment introduce the concept of "sometime in the near future" and "not always" they are ortongonal thus distributed transaction is something really strange, just kidding, well not so much :-) .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 ------------------------------------