Domain Driven Design with an EAV database model

Question

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?

UPDATE

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?

• MattDavey: Can you be more specific with your question?
• jgauffin: By using a repository
• Eric King: 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.
• Songo: @MattDavey I updated the question.
• Songo: @EricKing I understand what you mean. please check my update to get my real problem.

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).