Re: Same aggregate in 2 bounded contexts

I believe Suppliers doesn't have to be a BC. If there's not business logic and just CRUD operations, than you can just use a plain CRUD repository to deal with those simple operations. 
Disabling/enabling a supplier doesn't have to be business logic (in fact it is not). It's simply setting a Boolean in a database, let's say, which is the U in the CRUD. 

It's OK to have crud and DDD co-existing in the same system. As a matter of fact, it keeps sanity alive. It "cleans" up your domain and helps you focus on what is really business domain operations. 

Now, remember that you can have the "same entity" in multiple BC. They don't have the same meaning, but they are the same in an abstract point of view. 

Supplier in your BC 2 is the same as  Supplier in a future BC related to Accounting for example. It doesn't mean it is the same physical class/file, neither have to have the same properties. Just think of a Customer entity in a eCommerce app. You use it almost in every BC yet they represent an unique set of data and operations in each BC. Keep in mind that they also can point to the same "table" in a database thru your ORM mapping. 

I'm trying to help you with the concepts rather than the actual situation because I think that's where you're struggling. 

In my early days with DDD, analysis paralysis was an everyday bird on my tree. I solved it by just creating a basic class with all my operations and data and you will see immediately where to start refactoring  and breaking apart data and operations and voilà, there is your aggregate. :) 

Good luck! 


Sent from my iPhone

> On Jan 1, 2015, at 4:48 PM, [email protected] [domaindrivendesign] <[email protected]> wrote:
> 
> Let's model this scenario: We are trying to connect to different "Suppliers" via FTP. Each Supplier can have 1 or more FTP servers. We are going to download Inventory files from these FTP servers.
> 
> 
> I can identify 2 bounded contexts in this domain:
> Suppliers Bounded Context where I mange the life cycle of adding or disabling/enabling a supplier.
>  Suppliers Communication Bounded Context where  connect and download the inventory files from the ftp servers.
> In BC 1, Supplier is an entity with a model that has id, name, description,...etc. I think I'll also add a Supplier Type since we may need to connect to other supplier via different protocols other than ftp.
> 
> The problem is with BC 2. Is Supplier an entity? 
> 
> The FTP info (host, port, user, pass) is stored in BC 2 and I believe it's a value object. However, this value object should be tied to an entity. If I make Supplier an entity I'm guessing the only attribute it will need is the supplier id from BC 1. 
> 
> Does that make sense to have the same entity in 2 bounded contexts? Is it normal that the only attribute to be present in entity is the id?
>