How can one apply DDD to a EAV database model?

Consider this EAV database model: enter image description here

How am I supposed to build a domain model if all my entities and their attributes will be stored in the database?


To help clarify the question I'll give an example. If I'm building a Store that is going to sell some Products then I'll have 2 entities in my domain model corresponding to them.

Now my Product entity will normally have a fixed number of attributes (ex: Product_name, sku, weight, etc...). However, in a EAV model entities have a variable number of attributes.

How should I write a model for Product if each concrete instance of it will have a different number of attributes?

  • Can you be more specific with your question?
    – MattDavey
    Feb 18, 2013 at 17:21
  • By using a repository
    – jgauffin
    Feb 18, 2013 at 17:26
  • 5
    Keep in mind that the "Domain" in Domain Driven Design is the business domain, not the data domain. How your data is persisted does not effect how you model your business domain in DDD.
    – Eric King
    Feb 18, 2013 at 17:32
  • @MattDavey I updated the question.
    – Songo
    Feb 18, 2013 at 19:14
  • @EricKing I understand what you mean. please check my update to get my real problem.
    – Songo
    Feb 18, 2013 at 19:15

1 Answer 1


DDD says nothing with regards to how you are going to persist your data and you shouldn't concern yourself with such things when creating your domain model. Doing so will tie your domain to your database (or other persistence method) which kind of defeats the purpose of creating a rich domain model to begin with.

From: http://devlicio.us/blogs/casey/archive/2009/02/12/ddd-there-is-no-database.aspx

So Why “There Is No Database”? Domain Driven Design states specifically, in the name, why – we are designing our applications from the point of view of the Domain, and the Domain is drawn from the Ubiquitous Language we negotiate with our Domain Experts.

If we were to start with a database the it would be Database Driven Design. If we were to consciously or subconsciously bring elements from the database into our Domain, then we would risk compromising our Domain model purely to support the persistence layer we had chosen.

Looking at the database tables you gave the code for the aggregate in c# could look something like this:

public class MyDomainObject
    public int Id { get; set; }

    public IList<MyDomainObjectAttribute> Attributes = new List<MyDomainObjectAttribute>();

    public class MyDomainObjectAttribute {
            public string Name { get; set; }        
            public string Value { get; set; }

We can then use a mapper class or something similar (ORM, EventStore, etc...) to persist our aggregate to durable storage (be it a database or something else).

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.