Domain-Driven Design with Entity Framework & Repository Pattern [closed]

Question

I used to deal with simple apps that have Service Layer containing all of the business logic. In Domain Driven Design it's common to keep business logic in a rich model.

Watched a tutorial by Pluralsight in which they mention Repositories and noticed that a repo normally contains basic CRUD operations (create, update, fetch & remove entity). Nothing much was explained with regard to Entity Framework.

Entity Framework 6 & Entity Framework Core already provide Repository/UoW out of the box. I'm wondering if we can omit creating Repository Layer in this case?

So, how I imagine the app without a separate Repository layer...

My understanding is:

For example we have Customer model as an Aggregate Root (rich domain model). And that model has one-to-many relation ICollection<Payment> Payments. Plus, according to DDD - we keep our logic inside the model - so we have MakePayment method.

The code will be as follows:

public class Customer
{
    public virtual ICollection<Payment> Payments { get; set; }

    // ... other properties/collections

    public void MakePayment(decimal amount)
    {
        this.Payments.Add(new Payment() { Amount = amount });
    }
}

With Entity Framework we can eagerly load the entire tree with the result Customer already has all their Payments mapped.

(say, we deal with an ASP.NET WebAPI app)

So, in order to make a payment, I imagine, we do the following:

1. in our controller / service we fetch a customer (for example by id)

2. then follows the code customer.MakePayment(10);

3. after that we call dbContext.SaveChanges() method

4. DbContext tracks the changes and stores the payment - Bingo!

Is my understanding correct?

---

Regarding Service Layer:

Would it be okay to have Service Layer with DDD in such a web app?

I still think keeping the code in controller isn't necessarily the right thing to do (even with DDD) as long as e.g. part of functionality MAY BE required in a WPF app - so we can use Service Layer with it.

Seems like the most optimal approach, doesn't it?

Answer 1

I'm wondering if we can omit creating Repository Layer in this case?

As explained in first paragraph here, consider using Generic Repository (DbSet) directly. Avoid creating additional layer of Repository.

Is my understanding correct?

IMO, your understanding is correct if you have correctly implemented Unit of Work (Session Per Request as you explained in question) pattern. That is how it should work.

Would it be okay to have Service Layer with DDD in such a web app?

With DDD, your domain model includes the related logic. But, there is always a logic that does not belong to any domain model. That logic generally consumed in Services. So yes, you may still need Services with DDD. Just that, it will not contain all of your logic as most of it will be in models.

---

With DDD, consider using CQRS. With CQRS, you separate reads and writes to your data store. Repository is optional in this case. As suggested above, you can use Generic Repository exposed by ORM.

Answer 2

I'm wondering if we can omit creating Repository Layer in this case?

In my opinion, you cannot omit the Repository Layer. Generally, Repository is responsible for Save and Rebuild the Aggregate Root, and your domain entity is not your database entity. EF entity is not your domain entity.

Would it be okay to have Service Layer with DDD in such a web app?

Of course you can keep your Service Layer, actually, you can call it Application Layer in DDD, but you need care what should be include in this layer.