3

Based on my understanding of ddd, services are ideally defined around bounded contexts. And interaction between these services are mirrored with the relationship of their respective bounded contexts.

Things like, should a service interact directly to an api of a service, or whether it should just subscribe to an event topic, etc.

My question is which bounded context does these messaging components belong to? (Or even other infrastructure pieces like queues, load balancers, etc) enter image description here

This is a concern to me since we are highly watchful of how application infrastructure stacks are dependent to one another. For example, we try to avoid situations wherein 2 infrastructure stacks of separate bounded contexts have circular dependencies.

froi
  • 7,268
  • 5
  • 40
  • 78

4 Answers4

2

Long story short, it depends.
A cool tool of DDD is the context mapping that can help you.
In these situations, usually, a relationship of upstream and downstream bounded contexts can be found.
I will try to describe it, but doing your research about the topic will give you more details.
In case you have 2 bounded context integrating, the upstream service is the one that guide the contract, so changes to the upstream service will require a change into the downstream one.

To respond to your question, the queue should be part of the BC defining the operation, so if the message contract is like an event defined by BC B it can be part of it, otherwise if it is some kind of command defined by BC A it should be on that side.

In my vision, also if you can afford a proper team handling the infrastructure for all the BCs, each instance of queues, dbs and everything will always be part of a specific BC, and this could help also the team in charge of them to split their configuration/scripts to manage them in understanding how to partition and categorize them.

rascio
  • 8,968
  • 19
  • 68
  • 108
1

In general, components like those are best thought of as between contexts and not part of any particular context. Because a bounded context is a domain-level concept, infrastructure need not be considered part of any bounded context.

In the particular case of things like pubsub topics (as opposed to the infrastructure managing such topics), it may be useful in cases where there's exactly one context which publishes to the topic to declare such a topic to be part of that context, though other contexts (or their anti-corruption layers, which arguably exist between contexts) may depend on the topic.

Levi Ramsey
  • 18,884
  • 1
  • 16
  • 30
  • In the later scenario that you mentioned that it's useful to declare the topic to be part of the publishing context, what's the rationale for it? – froi Apr 15 '22 at 09:23
  • Where there's only one context that can publish to a topic (e.g. the topic is "events from this context") that topic is essentially (to use the CQRS terminology) a read model for that context. – Levi Ramsey Apr 15 '22 at 10:48
1

I think it should belong to the BC that dictates the contract. Compare it for instance with an upstream Open Host Service

Ton Donker
  • 51
  • 4
0

generic domain that can be used as a common component for each bounded context or a separate per bounded context.

Tushar Mishra
  • 1,370
  • 1
  • 12
  • 20