Using Event Sourcing and Master-Data-Management concepts together = Viable?

[Veniamin Goldin]

I am trying to model a data sharing between different Business Contexts, where the same Entities should be available to many Business Context, but with different sub-set of data. Something similar to what MDM tends to address. 

Suppose I have a CRM BC, which deals with the Customer Profile Management, and then I have a "Consumer Loans & Deposits (CLD)" BC which deals with Account Opening and needs to know whenever Customer is Active or not, before opening an Account.

Normally, I would use an Integration Events between BCs. My CRM BC would fire an Event that CustomerIsRegistered, and My CLD BC would consume the event and store in its own Customer Event Stream. However, almost all other BCs would be interested in the same event, leading to a CustomerIsRegsitered event to be stored in all the BCs of the system (x20). 

Would that be a valid design to have a Master-Data-Management BC, which will consume all the relevant events for a widely shared entities (i.e. Party, Customer, Product, Arrangement) and provide them as a shapshots for all the concerning BCs? The original events will be stored in their respectful BCs. The Entities in the "consuming" BCs would be populated using an Anti-Corruption-Layer, to minimize a sub-set of data and convert the language, if needed.  

Thanks.

Veniamin

[Greg Young]

You discuss optimizing for autonomy which can be good optimizing for authority can be good too. There are trade offs 

--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

[Veniamin Goldin]

Greg, 

How the optimization for authority would look like in that case? Do you mean saving event within consuming BC is the optimization for authority?

Could you please advice what are the trade offs for the "autonomy" option?

Thanks!

Sent from my iPhone

[Greg Young]

If everyone needs the information in the same way let everyone query it from a well known service I stead of storing it twenty times ... There are of course trade offs

[Veniamin Goldin]

That is exactly what I have proposed. 

To have a common service (MDM), which will be decoupled from the originating BC and consuming BC, and will provide query for consuming BC, which in turn will decoupled from the originating BC, but for the trade off of being coupled to MDM service. 

Thanks!

Sent from my iPhone

[Greg Young]

Sorry I meant the scenario you described not the solution you proposed when saying you were optimizing for authority (long day of flights and jet lag)

[Veniamin Goldin]

No worries :) Thanks, Greg!