CODEWITHSUNDEEP
domain-driven-designmicroservices
Robert
Robert

Reputation: 3553

DDD, Microservices and data direction

Let's assume I have Identity Management bounded context and discussion bounded context. Each of those is a separate micro service.

Identity has Users, Discussion has Moderators.

If I update first and last name in the Identity bounded context, my plan is to publish a message to Amazon SQS, and have discussion bounded context to listen that queue for any changes, and update first and last name in discussion context via Anti-Corruption layer.

My question is, what if I decide to change first name and last name in the Discussion BC? Should my Identity BS listen for that changes too, or having bi-directional communication is not considered a good practice, and I should always update that information inside Identity BC?

Upvotes: 2

Views: 322

Answers (2)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57307

Should my Identity BS listen for that changes too, or having bi-directional communication is not considered a good practice

I don't think bi-directional communication is necessarily the problem here. What concerns me is that you seem to have two different BCs acting as the "book of record" for identity.

In the blue book, Evans writes of bounded contexts being defined by meaning; when you cross from one context to another, you may need to change your understanding of what is understood by the common terminology: it doesn't necessarily follow that the rules for an aggregate in one context (User?) will be the same as in another.

The given example, User, is potentially more twitchy - because it may be that the real world, rather than the model, is the book of record, and the "aggregate" is really just a dumb bag of data.

If I use only reference id, wouldn't that mean that Discussion BC will not have necessary data in its domain

Necessary for what? Do changes in the discussion book of record depend on data stored in the Identity book of record?

Example for, in identity context i have user with username, first name and last name etc, but in discussion context I might have that same user but represented as moderator or poster with only necessary properties for that BC. If name changes in the identity context, it should propagate that changes to discussion.

That sounds as though you are describing it as necessary for your reads; as though you have a view of a discussion that includes a representation of the participants that includes their roles (which exist in the discussion BC) and their identities.

Reads tend not to be a very interesting use case, because reads don't change the book of record. As Udi hinted at, to build the view you basically need a reference id that you can use to pull the data you want out of some key value store. Is there any reason to prefer that the KV store is part of this BC as opposed to that one?

Consumers could be 3rd party companies and our company.

Connecting to the microservice(s) directly, or instead consuming an api that acts as a facade for the backing micro services?

Upvotes: 2

tomliversidge
tomliversidge

Reputation: 2369

How do people change their names?

I would try and have a single place where this is allowed, and have that context own the data. Other context can then subscribe to changes and act accordingly.

Upvotes: 2

Related Questions