Also, is it safe for a bounded context to invoke a command in another bounded context?
The simple demo’s I’ve seen do not introduce the complexity of more than 1 bounded context, so it is hard for me to determine what’s safe.
Any guidance would be appreciated.
This post seems to answer one of my questions, but I guess this assumes a shared kernel of commands that can be called from a different bounded context.
Would the same reasoning apply to subscribing to events from another bounded context?
IMO the cleanest way is to specify messages between bounded contexts explicitly.
Treating them the same as domain services incl. things like Anti Corruption Layer would be the DDD way to do it.
After a while, there may be some messages that are needed everywhere and become a common language.
However, every bounded context should use its own language which leads to messages, that are named differently , containing slightly different properties. These shouldn’t be forced into a common thing.
I think that’s what I mean by a shared kernel on my context map.
I can put the shared commands and events into a separate package or jar file that can be imported by the separate bounded contexts.
Is that the recommend practice?
Hi Wil and Johnny,
What Johnny says is I feel the right guidance to take, Wil.
Within a Bounded Context, your Messages/the API should be sharable with any component contained in it.
Thus, Commands, Events, Queries, and their possible responses should be freely sharable.
Between Bounded Contexts however, you share consciously.
Thus only the messages which are regarding to be common place between your Contexts.
So like I already pointed out, Johnny puts you on the right track.
However you decide to share the common language is up to you though.
Having a separate repository/jar/package/schema is all fine in my book, as long as you have separated the language within a Bounded Context from the language between Bounded Contexts.
Hope this helps.
Cheers,
Steven