Some tables in my database is designed using EAV concept. Then I use entities which are auto generated and represent "static" tables (not "EAV" tables) by ORM Entity Framework as DDD objects.
For example,
in the database I have static table Report and EAV tables which help me store ReportProperty for Report.
In domain model I want have Report like that:
Report
{
ICollection<ReportProperty> ReportProperties{get;set;}
}
I can use Report entity which is generated by Entity Framework and in partial section realise some logic in getter for retrieving data from my EAV tables to fill Collection ReportProperies. Then it begs the next question.
If I will be use DDD objects, which i can use for Entity Framework or NHibernate, it will be hardly for me, because I will need call mapping procedures in each procedures in my DAO.
EAV is a concept of the data access layer, while DDD is a concept of the business logic layer. ORM like Entity Framework or NHibernate tempt us to mix this both layers, but in complex projects with complex logic (that is where DDD is needed) this should never happen. So divide your Dal and Bll. Use hand crafted classes for you DDD objects and use auto generated (or code first) classes for Entity Framework and provide a mapping layer between them. Then EAV will be just an implementation detail of your Dal. Also your Bll and DDD classes wil not have to change, if you switch to NHibernate. Just your mapping Layer would. And by the way, use Dependency Inversion. Make your Dal depend on you Bll and not the other way around. If you make the mapping layer physically separate from your Entity Framework parts, then use mediator pattern on assembly level (meaning your mapping layer depends on your Bll and your Dal and not any other way around).