0

I am implementing a social network using the domain driven design. I have designed the Profile context which contains the userid, userName, profile pic and so on ... in this context the user can change his userName I have also a messaging context which is used to send messages between users, in this context I have a User class which contains the userID and the userName, noting that User is inside an aggregate. The problem is that the userName can be changed any time in the Profile context, that's why I choosed not to bind the message class with the user class, otherwise I'll get old message with the olds userName. Is there a mean so I can get the user lazily in the messaging context each time by asking the Profile context, and if yes is it good to use queries inside aggregates ?

Nabih Nebbache
  • 60
  • 6

1 Answers1

0

Is this the first time you are needing to get information from one BC to another? If not, how is information communicated from one BC to another in your system?

I find that the best way to communicate info across BCs is via the events that your Domain objects emit, and have your BC subscribe to those events, keeping local copies of the data. In your case you would:

(Assuming the Profile BC emits a 'userNameChangedEvent') Have your Messaging BC subscribe to that event, and have it persist the 'cut down' version of user - perhaps all it needs is the UserID and UserName. That way, when your user posts a message, the Messaging BC just queries its own slim User Table, to obtain the username.

The one caveat with this approach is with Eventual Consistency . That is, say a user changes their name, then immediately posts a message... how can you guarantee that the username has been updated on the Messaging BC by the time the message has been posted.

delagetto.so
  • 18
  • 5