Using the repository pattern, how do I reference my domain models without creating a leaky abstraction?

Question

Setup

.NET, C#, WebAPI, Entity Framework using code-first migration

Summary

I am designing a .NET solution using the repository pattern. The repository sits at the bottom of my stack and currently contains my domain models. I have layers on top of the repository (e.g. BLL) and finally I have an API layer on the top of the stack which contains my RESTful API endpoints.

Here is a simplified pseudo-diagram of the current solution stack:

-API -BLL -REPOSITORY

Problem

In the API layer, I would like to use .NET's ModelState validation inside each of the controller's endpoints. Problem is, this requires that the API layer have a reference to (ergo knowledge of) the Repository layer. Wouldn't this be a leaky abstraction?

It seems like the use of Data Transfer Objects would be the solution, but this almost seems silly since they would be essentially identical to the Domain Models in the Repository. That doesn't allow for much abstraction.

An alternative?

I am kicking around the idea of adding a separate project to contain the Domain Models, and then allow the API, BLL, and Repository to all reference that project. Any reason this shouldn't be done?

The only downside I see here is that now three of the projects in my solution will need access to the database:

• API (because I have set up OWIN authentication in the API)
• Repository
• DomainModels (because I am using code-first migration)

Any help is appreciated.

Answer 1

The repository sits at the bottom of my stack and currently contains my domain models

That's your problem, the repository uses domain entities, but it doesn't contain them. The repo is part of the persistence, your domain model should be part of the Domain layer. The repo interface is part of the Domain too.

ALso, you domain model should be different (as a concept) than you persistence model i.e the pocos you're using with EF to do CRUD stuff. The domain objects are modelled according to the business view, the persistence pocos are designed with db usage (store/easily queryable) in mind.

The domain layer should be at the core, persistence and application services should use it i.e depend on it. You can take a look at the onion architecture or business components/ vertical slices (which is a more advanced approach IMO)