Repository interfaces are be defined in the business logic component so the business classes can declare what their data access needs are. Remember that these are just interfaces — contracts for behavior. The actual implementation of those interfaces should be kept in the outer most shell of clean architecture. This allows you to swap out implementations if, say, your CEO suddenly gets a really, really good deal on SQL Server and suddenly you need to switch from Oracle, or maybe the technology ecosystem in which your system lives needs to utilized web services or microservices. The dependency points from the outer shell in clean architecture towards the inner circles. This is the intended direction of dependencies in clean architecture.

An entity in Entity Framework, your object relational mapper, means something different than what entity means in clean architecture:

Entities encapsulate Enterprise wide business rules. An entity can be an object with methods, or it can be a set of data structures and functions. It doesn’t matter so long as the entities could be used by many different applications in the enterprise.

^{Source: The Clean Architecture, Clean Coder Blog}

The emphasis here is that entities in clean architecture are part of your "business logic component." An "entity" in Microsoft Entity Framework can mean the same thing provided you spend the time to properly craft your data mappings. Many developers create an anemic domain model with Entity Framework, because it is easy and fast. And then there is no good place to put "business logic" so we go hunting for a suitable place, ultimately landing on a "service layer" or "more of essentially the same classes but in a different architectural layer." I think this might be the root cause of your question.

If classes are mapped in Entity Framework as an anemic domain model, then all you have created is data transfer objects used between your application and a relational database. Now things won't fit neatly into the layers of clean architecture, and, thus, the need for this question.

Entity Framework does allow you to map classes and properties with private setters, which helps maintain encapsulation, but this isn't perfect. I've not found a perfect bridge between a relational data model in the database and a behavior data model in an object oriented language. So, it comes down to compromise.

• Spend the extra time and effort crafting your data mappings so Entity Framework entities are not just big, dumb DTOs between your application and the database. They can contain business logic and maintain some amount of encapsulation.

• Accept that your business model will not a pure domain model. Some of the details of your data mappings will surely leak through. In my opinion, this is fine as long as you can still swap out your data layer with minimal effort.

Remember that all of the software architectures have a few common goals in mind:

• Invert the directions of dependencies so you can swap out the infrastructure of your application when you need to. Note that this is not necessarily "easy", but it should feel "possible."

• Promote testability. A testable application can be changed.

• Help developers organize large and complex code bases.

• Manage complexity.

• And (unfortunately) to sell books and lecture tickets.

  ^{This isn't a judgement on any one architecture. It's just an observation I've had over the years. It seems a few big names draw some variation of onion architecture, give it a different name and then sell a book.}

So, whatever you chose, keep the main goals of all these architectures in mind, and accept that those architectures are an ideal which does not reflect reality. Don't be afraid to compromise on the ideals.