CODEWITHSUNDEEP
domain-driven-design
user2586804
user2586804

Reputation: 321

Communication between contexts

I'm reading Implementing Domain Driven Design and struggling with the concept of context maps.

The language the book uses when describing how different contexts can communicate, "RESTful" "Open Host Service", "the other team" makes me wonder if I even have more than one context.

It's just me for a start, so there is no other team but I still want to segment my project into contexts, but obviously they need to communicate.

The contexts will be deployed in one process, so they can simply call each others methods, so no need for webservices in between each context, but the context map section of the book doesn't seem to deal with this.

So is there a name for how these contexts are communicating or is what I am describing therefore clearly one context because it's one team and no web services.

Upvotes: 1

Views: 185

Answers (2)

eulerfx
eulerfx

Reputation: 37739

Context mapping applies regardless of the actual transport implementation (in-process or HTTP). You can certainly have multiple bounded contexts at play even if you're a team of one. The book covers more complex integration scenarios to address the difficulties in coordinating multiple teams, however the principles apply regardless. For example, once you have multiple contexts implemented in a single application you may want to isolate them from each other simply for encapsulation purposes. If so, then creating an HTTP service to expose the published functionality of each context is an option. This can be desirable even if there are only a few developers working on the code base. What you should also consider is whether you actually have multiple bounded contexts. For example, you may have multiple modules, which is a way to partition responsibility within a single model.

Upvotes: 3

Martijn van den Broek
Martijn van den Broek

Reputation: 1381

A Bounded Context is about a Model. Single Model? Single Bounded Context. Multiple Models? Multiple Bounded Contexts.

Team organisation comes into play when defining the bounds of these contexts. One team can work in multiple contexts, and (with great care) multiple teams can work in the same context. The point is to make this explicit.

How you integrate Bounded Contexts (webservices, in-process, etc.) really doesn't matter. What matters is the type of relationship between the contexts - that will go into your Context Map.

Upvotes: 2

Related Questions