Богатая модель предметной области DDD — динамические зависимости — EAA

В дополнение к ответу Дока (с которым я согласен)

Это работает в реальном мире?

Да, но это не бесплатно.

Короче говоря, домен и постоянство — это концептуально разные модели, что делает необходимым преобразование друг друга. Две модели и один слой трансформации. Как вы можете догадаться, такое решение требует большой работы. В общем, сегрегация и разъединение связаны с этим.

Строго говоря о DDD, модель постоянства не имеет значения и, как сказал Док, она ортогональна предметной области. Домен (в идеале) не зависит ни от сохраняемости, ни от источника данных. Он передает Repositories, но никакие детали реализации не просачиваются в домен. В вашем случае ORM (картограф) будет одной из этих деталей.

Когда построен Product?

Когда это требуется доменом или бизнесом. Это может показаться слишком наивным, но это так. Прикладной уровень — это оболочка, основная цель которой — сделать определенные знания доступными и полезными. Приложение отправляет данные на бизнес-уровень, и бизнес использует знания предметной области для выполнения задачи. Между уровнем приложения и бизнес-уровнем может быть больше уровней, и один из них будет преобразовывать входные данные, отправляемые приложением на бизнес-уровень, в Product.

На всякий случай, если вы не заметили, ваш вопрос говорит о том, что вы смешиваете два представления Product. Один — это необработанные данные (записи базы данных или входные данные приложения), другой — данные и поведение. Другими словами, знания.

Первый является долгоживущим представителем второго. Он представляет собой состояние 2-го, в данный момент времени.

Второе — эфемерное представление, поскольку оно живет только в памяти и существует до тех пор, пока служит своей цели. Обычно столько же, сколько срок жизни пути выполнения.

Оба представления имеют разные жизненные циклы и создаются в разные моменты и по разным причинам. И все же они оба одинаковы. Две стороны одной медали. ¹

Как он узнает, какую стратегию внедрить в него?

Либо по конфигурации, либо по самим данным. Ничто не мешает вам хранить стратегию (имя, идентификатор, что угодно), привязанную к Product вместе с данными Product. И ничто не мешает вам оценить данные Product, чтобы во всем разобраться. Соотношение между Product - Strategy должно где-то жить.

Домен ожидает, что вы как-нибудь разберетесь с этим. Он говорит вам, как создать новый Product, но когда и как это чужая проблема.

Если вам повезет, ваш преобразователь будет достаточно настраиваемым и расширяемым, чтобы вы могли создавать экземпляры своих собственных объектов. В таком случае Product будет создан картографом. Скорее всего в Repository.

Где будет жить следующий код:

Мы часто называем это «где» уровнем косвенности. Это слой преобразований, о котором я упоминал в начале ответа. На этом уровне мы реализуем взаимодействие между моделями, которые должны оставаться независимыми друг от друга.

^{1: It's important to keep in mind that the persistence model and the domain model are driven by different forces. Strictly speaking about the persistence model, we design the persistence that best fits the needs for querying and retrieving. The forces driving the persistence model are not necessarily the same as those driving the domain. For example, data structures in}