I have two bounded context, one to handle files and another to handled bills.

I have two projects, one for each bounded contexts.

Files can be any kind of file, an image, a document in pdf or any other format and so on.

I have a many to many relationship between files and bills, in the way that a bill can be related with many files and a file can be related with many bills.

I would like to add the relationship between a bill with files.

For that, I have read some examples, like Udi Dahan and stack overflow question.

But in both examples, they use a reference to the instance of the related property, instead to use only the ID how it is recommended in DDD.

In my case, if I follow the examples, first I have to choose the root entity, in my case, is the bill entity which has a collection for files. So according to the examples, I would have something like this:

public class Bill : Entity
{
    long Id;
    string Reference;
    //Another properties

    List<File> Files = new List<File>();
}

My doubt, If I am not wrong, an entity only can have reference to another instance if the instace belongs to the aggregate. But In this case, I don't think File entity belongs to the aggregate, because the file shouldn't be manage from Bill entity, to avoid to can modify the file entity from a bill.

It is true that in one of the examples, the child entity, in my case File, only has the ID, so the entity would be this:

public class file : Entity
{
    long Id;
}

So I don't have the problem that I could modify the entity from Bill, I only have the ID.

But if I don't have a reference to File from Bill, how to stablish the relationship in the domain? I need the reference to can add the reference to the collection of files. If I only have a collection of IDs, it is not possible to stablish the relationship.

So in summary, I would like to know if the rule to don't have a reference to another entities that doesn't belong to the aggregate it is applied when I have to set a relationship between two different root entities or not.

Thanks.

I have two bounded contexts, one to handle files and another to handled bills.

I have two projects, one for each bounded contexts.

Files can be any kind of file, an image, a document in pdf or any other format and so on.

I have a many-to-many relationship between files and bills, in the way that a bill can be related with many files and a file can be related with many bills.

I would like to add the relationship between a bill with files.

For that, I have read some examples, like Udi Dahan and stack overflow question.

But in both examples, they use a reference to the instance of the related property, instead to use only the ID how it is recommended in DDD.

In my case, if I follow the examples, first I have to choose the root entity, in my case, is the bill entity which has a collection for files. So according to the examples, I would have something like this:

public class Bill : Entity
{
    long Id;
    string Reference;
    //Another properties

    List<File> Files = new List<File>();
}

My doubt, If I am not wrong, an entity only can have reference to another instance if the instance belongs to the aggregate. But in this case, I don't think File entity belongs to the aggregate, because the file shouldn't be managed from Bill entity, to avoid modifying the file entity from a bill.

It is true that in one of the examples, the child entity, in my case File, only has the ID, so the entity would be this:

public class file : Entity
{
    long Id;
}

So I don't have the problem that I could modify the entity from Bill, I only have the ID.

But if I don't have a reference to File from Bill, how to establish the relationship in the domain? I need the reference to add the reference to the collection of files. If I only have a collection of IDs, it is not possible to stablish the relationship.

So, in summary, I would like to know if the rule to not have a reference to another entities that don't belong to the aggregate is applied when I have to set a relationship between two different root entities or not.