How the Entity Framework Code-First mappings reflect the domain driven design?

Question

I wish to use Entity Framework Code-first for a new project. So i decided to do some research and build some demo so that i can see how its doing. Through, i have a major problem or probably more something that isnt clear to me that involve the way entity framework code-first map to the entities and the domain driven design.

As we build an application, we define the domain entities. (we define aggregates roots and make repositories for them depending on the business situation from what ive heard)

That okay but Entity Framework Code-First mapping seem to work like a relational way between entities. So how both can coexist ?

As an example (Thinking at domain driven design side) :

Journal contains JournalEnty contains tasks, problems, notes

Italic words are entities. In some way after analysis i would say that the journal is the aggregate root of the aggregate journal and journalentry since this is a direct composition. Each tasks contain an hour value to know how much hours it taken to finish the tasks so there much be a way to calculate the total hours and also the salary coming from this. The journal have the hour rate property.

The others entities are each an aggregate root and they might have a reference to the journalentry so we know where the tasks, notes and problems belong.

But the problem come here.. how the Entity Framework Code-First mapping can reflect this ? From an intuitive view we would say that the journal contain a journal entry and that the journal entry contains notes, problems, and tasks. But from DDD view that probably not the case. Correct me if i am wrong but code-first work like a relational database.

So how we would map the example above in code-first ?

Thanks a lots.

Answer 1

I think that it is not bad if each domain entity have corresponding table in the database. And it doesn't mean that it is relational structure as Journal object has JournalEntity property (in relational structure journalEntity just has JournalID). Moreover it is possible to map objects hierarchy to one table and create Complex Types in your mappings. It means that you can have more complex mapping scenarios then class per table.

Here is ScottGu blog post about it.