1

This question is related, but more specific than this question.

I'm going to use a simple example here. Say we have a User entity in one context and a Customer entity in another context. These are 2 different representations of the same entity.

Let's say the User and Customer both have an email address, but the email address is always changed via the bounded context that the User belongs to. So the user context is the source of truth for the email address. So ideally I would like the email address in the Customer context to be immutable from the point of view of the customer context.

So when the email address is changed in the user context, an EmailAddressChanged event is emitted. This is fine; I subscribe to the event in the Customer context. However, I now need to handle this event by mutating the Customer email address. So I need some sort of command method to make this change.

How can I ensure that the command method is not used, other than when handling the event from the User context?

If I allow mutation in both contexts then they both become sources of truth and I need double the number of events and handlers to ensure that the information remains consistent in both contexts

Community
  • 1
  • 1
rgvcorley
  • 2,883
  • 4
  • 22
  • 41
  • Possible duplicate of [Communicating between two Bounded Contexts in DDD](http://stackoverflow.com/questions/16713041/communicating-between-two-bounded-contexts-in-ddd) – guillaume31 Mar 10 '17 at 13:13

1 Answers1

2

Maybe there is a hidden customer/supplier relationship between these bounded contexts? If User bc is the source of truth for Customer bc, then User bc might expose an API to be accessed by downstream contexts (Customer, maybe something more?). In your question you said only the email address should be "immutable" and dependent on User context - however, I think it might a hint that entire Customer context is a consumer/customer of User context and should use its public API (which should not expose internal user domain model directly - some facade classes are required to hide the details).

If that's not the case, and there is no such relationship between the contexts - you can use a specialized component in your Customer bc to make changes to the database, without directly invoking domain methods. Then, the repository can be used to query customers and recreate them with updated email address. My point is - if you want customer bc to apply EmailAddressChanged events, you obviously need something to alter the database, but you don't need to do that via domain methods. The component applying EmailAddressChanged events would be part of the infrastructure layer of Customer context. If you use this solution, then there is no risk of modifying customers via business case scenarios.

Btw, isn't your Customer in fact a specialized read model of User context?

Mike Wojtyna
  • 751
  • 5
  • 10
  • I like the idea of accessing the database directly. Another thing I thought of was using a command object with a shared secret, so issue the command object to modify the Customer entity, but only the service that handles the event from the User context knows the shared secret and can issue that command. Another idea that someone suggested was to use a projection, rather than store the data in the foreign aggregate. – rgvcorley Mar 10 '17 at 11:36
  • Could you elaborate more on the projection idea? – Mike Wojtyna Mar 10 '17 at 17:37
  • So you would subscribe to the change events from the User context in the Customer context and update a projection of the `User`, so there would be a database table 'projection' with the user information, as appose to storing the information on the `Customer` aggregate – rgvcorley Mar 13 '17 at 15:11