How can one apply DDD to a EAV database model?
Consider this EAV database model:
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?
6
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).