Re: Re: Same aggregate in 2 bounded contexts

I didn't know you had two different databases. In that case, like I told you earlier, use events to notify BCs about changes. That way you can pass in the event an identifier of your Supplier and each BC identifies the entity, retrieve it using repo, modify it and save it. You can have multiple even listeners listening to a particular event. 

Sent from my iPhone

> On Jan 3, 2015, at 1:41 PM, Greg Young [email protected] [domaindrivendesign] <[email protected]> wrote:
> 
> There is a difference between a bounded context and a service.
> 
> Have you looked into raising events about suppliers?
> 
>> On Sat, Jan 3, 2015 at 3:56 AM, [email protected] [domaindrivendesign] <[email protected]> wrote:
>>  
>> I think I should have mentioned that each BC will have its own database and it will run on a different server and maybe managed by a different team.
>> 
>> 
>> So when our commercial team for example decides to disable a supplier they do it through the Suppliers BC.
>> 
>> The operations team on the other hand is managing the upload and download of files from the ftp servers. It feels wrong to give them the ability to disable a supplier as its not up to them to make that decision.
>> 
>> So we chose to dump the suppliers table from BC 1 to all interested services to provide the data they require (whether a supplier was disabled in this case specifically).
> 
> 
> 
> -- 
> Studying for the Turing test
>