Disclaimer: I'm not 100% sure I understand some of the practices and concepts in DDD, so this question may actually be answered by clarification of the ideas

I'm working in a legacy system (written in PHP) in which the database tool provides no object relational mapping, and thus objects coming out of the database access layer tend to be, more or less, mirrors of the rows returned by the query.

For newer modules, I'm trying to apply DDD. However, I'm struggling with how to build a rich domain model when my entities have no relations. Take for example the following requirement: users can see the messages they have previously accepted, where a message being accepted is, internally, recorded by a single new row in a database table.

Were I using an ORM and did my entities have relations, I may write something akin to $user->getAcceptedMessages(), which would return a collection of message entities. However, since I don't have that, I'm torn between two approaches:

  1. Populate the relations as part of the building of the entity in the repository. The queries could get big, unwieldy and hard to maintain as the number of relations grows and the schema changes.
  2. Create services for actions such as this, which depend on the repository and a take a user, eg UserMessageAcceptanceService. However, I suspect this might lead to an anemic domain model.

Is either approach sensible in this scenario? Or is some form of ORM a requirement for applying DDD effectively?

1 Answer 1


DDD is about modeling the business cases. It has nothing to do with how the entities and relations are persisted. DDD was actually conceived in time when ORM was not much used and when you read the original DDD book, you will notice they talk a lot about using pure SQL for persistence. That is why Repositories in DDD exist. Just because you don't persist the relations in DB doesn't mean your entities don't have them. They do.

In your case, both solutions are possible. Actually using both in single project is best way, because both have it's advantages and disadvantages. In second case, it would actually be better if such method was part of the repository itself. There is no need to create specific service. Third option would be to use lazy-loading like behavior in getAcceptedMessages method and load the data only on request. But you should be careful with that.

  • 1
    It's my understanding (though possibly incorrectly) that a repository should be dumb and only know about how to persist and retrieve entities. Would placing a method like getAcceptedMessagesForPerson in the repository constitute adding business logic to it?
    – Andy Hunt
    Commented Jun 27, 2014 at 9:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.