Clean Architecture (or its .NET-specific variants like Onion Architecture and the Vertical Slice approach) has become the default structural choice for serious .NET applications. The core idea is sound: business logic at the centre, infrastructure at the edges, dependencies pointing inward. Most teams understand this in theory. The problems emerge in the specifics.
Anemic domain models
The most common mistake is treating domain entities as data containers and putting all business logic in the application layer. You end up with classes that have properties and no behaviour, and a service layer that manipulates them directly. This is not Clean Architecture with a domain model. It is a transaction script with extra folders.
If the Order entity has only getters and setters, and an OrderService is responsible for knowing when an order can be cancelled, what its valid state transitions are, and how to calculate its total, the domain model is not doing any work. The business rules are scattered across services, duplicated over time, and impossible to test without instantiating the entire application layer.
The fix is to put behaviour on the entities. Cancellation logic belongs on the order. State transition rules belong on the order. The service layer orchestrates and delegates, it does not contain the business decisions.
Leaking infrastructure concerns inward
The dependency rule states that inner layers cannot depend on outer layers. In practice, this is violated most often through EF Core entities in the domain layer. When your domain model implements IEntityTypeConfiguration, inherits from a base entity with navigation properties shaped for the ORM, or uses attributes like [Required] that belong to data annotations, the domain layer has taken a dependency on EF Core. The direction of dependency is inverted.
The correct approach is a persistence model separate from the domain model, with a mapping layer between them. This adds code. It is the right trade. Your domain model should be expressible as plain C# classes with no framework dependencies, and your tests should be able to instantiate and exercise them without a database connection.
Over-abstraction in the infrastructure layer
Going the other direction, some teams abstract everything in the infrastructure layer: a repository interface for every entity, a generic repository on top of that, a unit of work abstraction around EF Core's own DbContext, which is already a unit of work. Each abstraction adds indirection with no corresponding benefit, and makes the codebase harder to navigate without making it easier to test or change.
The guideline worth following: abstract what you actually need to replace or mock. If you are never going to swap EF Core for Dapper in this application, a repository interface that wraps EF Core one-to-one is not an abstraction, it is noise. Abstract the query, not the persistence mechanism.
Treating the pattern as a folder structure
The most superficial failure mode is creating Domain, Application, Infrastructure, and Presentation folders or projects, moving files into them, and considering the architecture done. The folder names are not the architecture. The dependency rules are the architecture. A codebase where the domain project references the infrastructure project is not Clean Architecture regardless of how the folders are named.
The test is simple: can you compile and unit test the domain and application layers without the infrastructure layer present? If yes, the dependency rule is being enforced. If not, the structure is decorative.