EF 4.2 Code First и проблемы проектирования DDD
У меня есть несколько проблем, когда я пытаюсь сначала выполнить разработку DDD с кодом EF 4.2 (или EF 4.1). Я провел обширное исследование, но не нашел конкретных ответов на свои конкретные проблемы. Вот мои опасения:
Домен не может знать об уровне сохраняемости, или, другими словами, домен полностью отделен от EF. Однако для сохранения данных в базе данных каждая сущность должна быть присоединена или добавлена к контексту EF. Я знаю, что вы должны использовать фабрики для создания экземпляров совокупных корней, чтобы фабрика могла потенциально зарегистрировать созданный объект в контексте EF.Похоже, что это нарушает правила DDD, поскольку фабрика является частью домена, а не частью уровня сохраняемости. Как мне приступить к созданию и регистрации сущностей, чтобы они правильно сохранялись в базе данных, когда это необходимо?
Должна ли агрегированная сущность создавать свои дочерние сущности? Я имею в виду, что если у меня есть
Организацияи этаОрганизацияимеет набор объектовСотрудник, должнаОрганизацияиметь такой метод какCreateEmployeeилиAddEmployee? Если нет, то при создании сущностиСотрудникследует иметь в виду, что агрегированный кореньОрганизация«владеет» каждой сущностьюСотрудник.При первой работе с кодом EF идентификаторы (в форме столбцов идентификаторов в базе данных) каждого объекта обрабатываются автоматически и, как правило, никогда не должны изменяться кодом пользователя. Поскольку DDD заявляет, что домен отделен от постоянного игнорирования, кажется, что раскрытие идентификаторов - это странная вещь, которую нужно делать в домене, потому что это подразумевает, что домен должен обрабатывать присвоение уникальных идентификаторов вновь созданным объектам. Следует ли мне беспокоиться о раскрытии свойств идентификаторов сущностей?
Я понимаю, что это своего рода открытые вопросы проектирования, но я стараюсь изо всех сил придерживаться шаблонов проектирования DDD, используя EF в качестве уровня сохраняемости.
Заранее спасибо!