DDD and DB first, is domain objects needed? RRS feed

  • Question

  • User-457790453 posted

    I'm working on a project that is following the DB first approach and EF is used for persistance. So we have an edmx file that generates the entity objects, but on top of that we are creating Domain Objects classes that maps to the EF objects which in turn maps to the DB. Also on top of DO we are creating DTOs that are passed to the application layer via the repository methods and those methods are accessed via the services layer from the controller actions.

    I'm seeing that the DO objects that we are creating are useless and they are nothing more than a replication of the EF classes, is this true? and what can be a better approach to design this?

    Sunday, September 18, 2016 4:40 PM


  • User-821857111 posted

    If you start with the database, you cannot be using DDD by definition. If you are creating domain objects that are basically no more than copies of the objects defined in the edmx, you should consider getting rid of the edmx file altogether and using a code first approach. That way you can practice DDD. 

    Repositories normally return domain objects. The only time I return something else is if I want to return a projection - a subset of the data represented by the entity.

    DTOs are intended to be used to represent data being transferred across processes - e.g. by Web-based APIs. There is no place for them purely within the confines of an MVC app. The only other type of object you should define is a view model - an object that represents all the data required for a view. 


    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, September 18, 2016 8:48 PM