And a second question. If I would like to use projections for example, or another more advanced feature of EF, that it is possible to need also in small projects. All this code, would it have to be implemented in the controller? If this is the case, the controller becomes more complex.

Thanks for the answer. I understand for small projects it could be over engineering, but if in the future I want to update to a new version of entity core, that perhaps changes methods, or change behaviour of some methods, that has passed in the past. Wouldn't it too much work change the code of all controllers and check if it works? If I implement a new repository that I test that it works as the controllers expect, wouldn't it better?

I am agree with this idea, and I am thinking how to implement it, but i don't find the best way to do it. Could you show how could I implement it? Thanks so much.

About if this is a aplication layer centric instead of domain centric solution. I could be wrong, but for me the application layer is the layer that coordinate different elements. In a basic action, 1.- get the data from the repository, 2.- call the methods of the domain and 3.- save the changes. If the domain use the interface to get the data and persist it using the interface, which is the responsability of the application layer?

Thanks for the detail answer. But to clear when I tell that the domain should be agnostic about persistence, I wanted to mean that the domain shouldn't know if the data is persisted or not. If the repository is defined in the domain, the domain is asumming that the data will be persisted, and if it defines an interface it means it will use in some moment, so the domain will decide when to persist the data. So the interface it makes the domain agnostic about technology, but not about if the data is persisted or not.

@RikD Bill doesn't need the file to acomplish any task, just I want to stablish a relationship between a bill and a file. But the bill doesn't need a file to pass from created to paid or some other task. But if I only should to use the file with bills if a bill needed it to acomplish a task, how could I set the relationship between the file and the bill? I need another domain for that, whick task is to create or delete a relationship between the bill and the file?

When I talk about bounded context, I mean that I have a system (a bounded context) to manage files (create, update, delete and any other actions that I could do about files). And when I talk about bounded context for bills, it is to manage bills (create, update, change states...). So I could manage files if I bill is offline and I can manage bills if files are offline. Is this correct? Perhaps I misunderstood this.