I am new to DDD, having worked only in Transaction-Script apps with an anemic model, or just Big Balls of Mud, so please forgive any terminology I abuse.

I am trying to understand the proper separation between the domain model and the repository. What is the proper way to construct a domain object that is coming from a database, assuming the (incredibly simplified) need to query for objects by status (returns enumerable), or by ID.

  • Should a factory be building the objects, exposing methods for GetByStatus() and GetByID(), using a DIed repository?
  • Should a repository be called directly, knowing how to build a domain model from the DTO?
  • Should the domain model have a constructor for get by ID, using a DIed repoistory to load the initial state, using some other (?) method for the list?

I am not really sure what the best way would be, and this question has an answer advocating each one (these are certainly mutuallu exclusive).

1 Answer 1


Repository is a service of domain model, that has responsibility of serving as layer between your domain and data store. It should have method to query entities and methods to save and update them.

To answer your question:

  • I would say no. I think if you use factories to create your domain object, it should be obvious that domain object comes from data store and is not created anew.
  • Yes, if you want to. I think this is pretty close to implementation detail and can be left on you.
  • Definitely not. Like I said, it should be obvious where the entity is coming from.

Also, if you are using an ORM framework, then this framework is already form of repository. Make full use of it and don't reinvent the wheel or add unnecessary layer of complexity over it.

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.