0

In "Implementing Domain-Driven Design", Vernon give detailed examples for integrating bounded context with a messaging or REST based solution, it also mention database integration, but I understand it is not a very clean solution to share database or at least db tables between BC.

But what if the 2 BCs I want to integrate are hosted locally on the same server, is it really a good idea to use a messaging/rest/rpc solution ? (which seems more suitable for a remotely hosted BC to me)

Otherwise, except with DB integration, what are the other alternatives ? Hosting both BC in the same process and calling it directly (still using adapters and translators for clean seperation) ?

Thanks

Jonathan
  • 1,276
  • 10
  • 35
  • 1
    As mentioned you can use ZeroMQ or (for .NET) MediatR to implement pub-sub in memory. But sharing data means spreading ownership and it also means your contexts are no more bounded. – Alexey Zimarev Aug 12 '16 at 14:50

2 Answers2

2

You could look into using something like 0MQ for inter-process communication on the same server. I've also in the past just hosted things in the same process as you suggest and just used interfaces / in-memory messaging to separate out contexts.

Everything is about trade-offs in the end, so you just need to decide what level of isolation you are willing to accept. The simplest solution would be to separate inside a solution via folders and interfaces, the other end of the spectrum being completely separate servers.

tomliversidge
  • 2,339
  • 1
  • 15
  • 15
1

I don't think that location should come into play w.r.t. integration between BCs.

There really are other factors to consider such as guaranteed delivery to the recipient in order to ensure that the processing takes place. This should be required whether or not the two BCs are hosted on the same server.

Another reason to ignore location is that when you need to scale, your architecture should be able to handle it from the get-go.

As tomliversidge mentioned it is possible to use some deployment mechanisms such as non-durable messaging to speed up things but there will definitely be a trade-off and that has to be a conscious decision.

Eben Roux
  • 12,983
  • 2
  • 27
  • 48
  • ok, thank you for your reply. But is it really important to use a "remote-integration-type" from the beginning even if we won't plan to deploy on multiple servers for now ? If we do it correctly can't we integrate in the same process now which would be faster and simpler and just change the adapters later if we need to separate processes or servers ? – Jonathan Aug 12 '16 at 12:41
  • You could do that @Jonothan. Just keep in mind that you probably are going to be after consistency so as long as the mechanism you use allows all changes to be guaranteed then you are going to be OK. However, would that perhaps entail distributed transactions or even a transaction spanning two BCs? If so you may run into some major refactoring later on. If you can get away with implementing with this in mind now and it doesn't take much additional time or effort it *may* be worth considering. Not "future-proofing" though, just trying to prevent extra work going forward :) – Eben Roux Aug 13 '16 at 04:11