2

I was reading nginx article regarding Inter-Process Communication in a Microservices Architecture, and I found this diagram.

What surprised me is the second BC, where trip management BC actually leaves its BC in order to get passenger info from a different BC.

I know it is strictly a business logic if a trip management BC can afford to rely on outside BC, but isnt the sole purpose of bounded context to provide higher level of automicity and avoid BC leave its bounderies in order to serve this solution space?

enter image description here

Improve this question
6
  • 1
    When you need information that is outside of the bounded context.
    – Robert Harvey
    Nov 22, 2016 at 16:46
  • Steve Harvey is that you?
    – John
    Nov 22, 2016 at 18:30
  • Ah, I see that you noticed the irony. Nothing in computing is as black-and-white as most programmers want it to be.
    – Robert Harvey
    Nov 22, 2016 at 18:40
  • Then patterns and principles shouldnt exist. Not looking for a black and white solution, just an advice on ddd
    – John
    Nov 22, 2016 at 19:46
  • If by that you mean patterns and practices shouldn't exist unless they're ironclad, i'm inclined to disagree. There isn't any pattern or practice that exists that is strictly black and white, so if you insist on that distinction, patterns and practices are not going to be useful to you. That doesn't necessarily mean they won't be useful to others who have a less dogmatic point of view.
    – Robert Harvey
    Nov 22, 2016 at 19:48

1 Answer 1

Reset to default
5

All things being equal we would probably prefer to use a single BC for everything. But that is simply not possible for a number of reasons.

First, there is always an ecosystem surrounding any single system, and frequently the system needs to interact with other systems in the ecosystem.

Those other systems are hosted by differing organizations (companies, departments, agencies) with different responsibilities, different motivations and business goals, and possibly different legal/regulatory requirements. Those varied organizations will often want to host their services in their own way independent of the other members of the ecosystem.

Second, splitting a BC into multiple BC's is a method for scaling the system, both in terms of peak load, yet also in terms of facilitating loosely coupled independent parts to foster easier development, evolution, maintenance, and operations. (There are long term advantages to having multiple BC's, but there are also costs in complexity.)

In this particular case, the passenger management may store customer account information, possibly including login/password, payment information (credit card), personal preferences, among other. The system designers may feel that is important data to secure and to develop for fostering and maintaining good customer relations. Logically speaking this customer system is probably a much bigger system than being shown by this one service flow, so it is being treated as an independent BC.

isn't the sole purpose of bounded context to provide higher level of automicity[sic] and avoid BC leave its boundaries in order to serve this solution space?

The primary purpose of the Bounded Context in Domain Driven Design is to provide the context for the modeling of a domain. Each BC hosts a Domain Model that starts with well-defined concepts/terms (vocabulary), their relationships, and their behaviors. Every component or service in the BC should be designed to fit properly into the BC's domain model.

The BC is effectively a unit of contextual and conceptual design, and by extension then, also a sort of unit of implementation (as implementation follows the designs of the domain model). That the BC tends to provide either autonomy or atomicity depending on what you were going for, is more of an natural extension of treating each domain model and its BC as a unit to be implemented, and that within that unit of implementation we expect its sub-components to have tighter couplings than those occurring between BC's.

Improve this answer
2
  • You reasoning is perfectly valid, but I must say it somehow does not follow of ddd basic rules. If passenger management system is to big, or it is hosted on a different server designed for much higher load, etc etc, shouldn't passenger have a different meaning in trip management BC and would likely need only a portion of data stored in passenger man. BC. I am aware there is no one solution fits all, but would it be more natural to have that fragment of info be stored in trip man. using ubiquitous language from trip man.?
    – John
    Nov 24, 2016 at 7:18
  • @John, I'm assuming that between the two BC's there is appropriate anti-corruption layering having mapping between their domain models. So, to your question, yes, we would expect trip manager to have vocabulary around passengers in its domain model, and to hold references to passengers (aggregate roots) in the other BC, and maybe even along with some local adornments. Still, that doesn't necessarily eliminate the need for one BC to talk to the other; the pass. BC may authorize, or do billing, or preferences, and it may not be reasonable for the trip BC to take over those responsibility.
    – Erik Eidt
    Nov 24, 2016 at 15:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.