Which objects should contain the database access methods in domain driven design

Question

I thought domain driven design is saying the Get-methods are in the Repositories and the Add/Del/Update are in the business objects?

Can you clarify this please?

When I look at the MVCMusicStore sample all CRUD methods to the database are in the entities ?!

http://mvcmusicstore.codeplex.com/SourceControl/changeset/view/d9f25c5263ed#MvcMusicStore%2fModels%2fShoppingCart.cs

score 2 · Answer 1 · edited May 23 '17 at 12:27

2

I've just answered a similar question could domain models be aware of repositories? (and also Does "Save" method belong to the Business Domain Entity? ) - and it seems that many many DDD questions are about Active Record vs. Repository choice.

I'd follow Eric Evans advice

In general, don't fight your frameworks. Seek ways to keep the fundamentals of DDD and let go the specifics when the framework is antagonistic. Look for affinities between the concepts of DDD and the concepts of the framework. This is assuming that you have no choice but to use the framework.

So, even if the creator of DDD is aware of some possible inconveniences, for me the choice between Active Record and Repository depends on the current stack of technologies.

edited May 23 '17 at 12:27

Community

1
1

answered Aug 05 '12 at 19:11

Boris Treukhov

17,493
9
70
91

"for me the choice between Active Record and Repository depends on the current stack of technologies." You mean ADO.NET 2.0 (Raw Sql) vs ADO.NET 4.0 (ORM) ? – Elisabeth Aug 10 '12 at 10:09
@Elisa Actually I meant a higher level frameworks and tools that provide the implementation of these patterns. Some tools are biased to one of these patterns from the very beginning and it may be simpler either to change the tools for something else or to adhere to the decisions made by the framework developers . – Boris Treukhov Aug 10 '12 at 12:15
p.s. concerning the pure ddd, casablanca's answer is the way to go of course – Boris Treukhov Aug 10 '12 at 13:23

score 2 · Answer 2 · answered Aug 06 '12 at 04:41

The link you posted isn't an example of domain-driven design, it simply illustrates the MVC pattern. As you mentioned, the entities contain all persistence logic while the business logic lies primarily in the controllers.

In a domain-driven design of the same system, entities would not contain any persistence logic but they would contain most of the business logic. All persistence functions would reside in repositories, and the controllers (a.k.a. services) would be extremely thin and delegate most of the work to entities.

score 0 · Answer 3 · answered Aug 07 '12 at 14:01

Here's what a typical repository looks like:

public class OrderRepository {
    public MyClass Load(Guid id); // throws an exception if not found
    public void Save(Order order);
    public void Delete(Guid id); // does not throw an exception if not found (idempotent)
}

Which objects should contain the database access methods in domain driven design

3 Answers3

Linked