Как сопоставления Entity Framework Code-First отражают дизайн, управляемый доменом?

Я хочу использовать Entity Framework Code-first для нового проекта. Поэтому я решил провести небольшое исследование и создать демо-версию, чтобы увидеть, как она работает. Таким образом, у меня есть серьезная проблема или, возможно, нечто большее, что мне непонятно, что включает в себя способ сопоставления кода структуры сущностей с сущностями и дизайн, управляемый доменом.

Когда мы создаем приложение, мы определяем сущности домена. (мы определяем агрегированные корни и создаем для них репозитории в зависимости от бизнес-ситуации, о которой я слышал)

Это нормально, но сопоставление Entity Framework Code-First, похоже, работает как реляционный способ между сущностями. Так как же оба могут сосуществовать?

В качестве примера (мышление со стороны дизайна, основанного на предметной области):

Journal содержит JournalEnty содержит задачи , проблемы , примечания

Курсивными словами являются сущности. В некотором смысле после анализа я бы сказал, что журнал является совокупным корнем совокупного журнала и журналов, поскольку это прямая композиция. Каждая задача содержит значение часа, чтобы узнать, сколько часов потребовалось для выполнения задач, поэтому есть способ рассчитать общее количество часов, а также заработную плату, полученную из этого. У журнала есть свойство почасовой ставки.

Все остальные сущности являются совокупным корнем, и они могут иметь ссылку на журнал, чтобы мы знали, где находятся задачи, заметки и проблемы.

Но проблема здесь .. как отображение Entity Framework Code-First может это отразить? С интуитивно понятного представления мы бы сказали, что журнал содержит запись журнала, а запись журнала содержит заметки, проблемы и задачи. Но, с точки зрения DDD, это, вероятно, не так. Поправьте меня, если я ошибаюсь, но код сначала работает как реляционная база данных.

Так как же нам сопоставить приведенный выше пример в коде сначала?

Большое спасибо.