Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
561 views
in Technique[技术] by (71.8m points)

domain driven design - Communicating between two Bounded Contexts in DDD

I have few different Bounded Contexts in the domain. The validation of a CRUD operation is built in each Bounded Context.

For example, I can create an entity called GAME only if the person creating it is a Group Leader.

I have two Bounded Contexts (BC) in this example. One is the Game BC and the other is the User BC. To solve the problem, in the Game BC, I have to make a domain service call like IsGroupLeader() to the User BC before proceeding on creating the Game.

I don't think this type of communication is recommended by DDD. I can have a User entity also in the Game BC, but I don't want to because the same User entity is being used differently in a different context in a different BC.

My questions are:

  1. Should I use Domain events where the Game BC has to send an event to the User BC asking the status of the User? With this approach, I don't make a synchronous call like IsGroupLeader but an event called is_group_leader. Then the Game BC has to wait for the User BC to process the event and return the status. The Game BC will create the Game entity only after the User BC process the event.

  2. Is CQRS a solution to my problem?

Any idea appreciated.

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

When integrating BCs, you have a few options. The reason that calling out to an external BC is discouraged is because it requires for both BCs to be operational at the same time. However, this is often quite acceptable and is simpler than the alternative. An alternative is to have the Game BC subscribe to events from the User BC and keep local copies of the data it needs, which in this case is information about whether a user is a group leader. In this way, when the Game BC needs to determine whether a user is a group leader, it doesn't need to call out to the User BC, it just reads locally stored data. The challenge of this event-driven alternative is synchronizing the events. You have the make sure the Game BC receives all appropriate events from the User BC. Another challenge is dealing with eventual consistency, since the BCs may be slightly out of sync at any given point in time.

CQRS is somewhat orthogonal to this problem.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...