Ваше описание проблемы является типичным примером из учебника, когда слишком много слов о «это хорошо, это плохо» становится причиной, по которой разработчик создает программное обеспечение так, как оно создано, вместо того, чтобы смотреть на проблему и создавать программное обеспечение для исправить эту проблему.
Показательный пример: описание вашей проблемы не ваша проблема, которую нужно решить: у вас есть приложение, которое нужно создать для вашего клиента, это проблема, которую вы должны решить. Если ваш выбор инструментов усложняет вашу жизнь, выгоните их и используйте то, что работает: если насмешка не работает, зачем беспокоиться? О, потому что кто-то сказал, что твое программное обеспечение отстой, если ты не издеваешься? Почему?
Вы кое-где подобрали DDD, но пропустили несколько важных частей: продукт является совокупным корнем. Это означает, что вы должны получать продукты из собственного хранилища. Да, это смягчает навигационную функцию в модели, но для вас это DDD, ЕСЛИ вы создаете репозитории строго так, как диктует вторая часть книги Эванса. Но ... ты должен?
Если вы не можете ответить, почему у продукта есть собственный репозиторий, но вы можете перейти к продуктам из заказа, вам не следует создавать репозитории для совокупных корней. ПОЧЕМУ это хранилище? Если это там, разве это не должно быть ЕДИНСТВЕННОЙ точкой, где Продукты доступны? (так тоже не через ленивую загрузку!).
Это действительно создаст много накладных расходов и кода, который вам, скорее всего, не понадобится (по иронии судьбы, YAGNI в полном объеме).
Хорошо, достаточно разглагольствования. DDD - это все о мышлении . Таким образом, домен должен управлять дизайном, и на практике вы получите модель домена, которая представляет реальность. Это не значит, что вы должны реализовывать много кода только потому, что читаете где-то, что должны. Вместо этого, если вы узнали элементы домена, совокупные корни и т. Д., Вам нужно где-то разместить поведение для этих типов, например, внутри доменных классов. Вы можете разместить логику выборки в отдельных классах, например, в логике выборки, ориентированной на порядок, в репозитории Order, но в строгом смысле это не будет репозиторий (например, у него нет собственного локального кэша и т. Д.). Это не так уж плохо, это все о том, что вы должны создать для своего клиента.
Итак, во-первых: думай, во-вторых: думай, а в-третьих: думай ... снова. Что кажется вам логичным. Составьте список плюсов / минусов вариантов, которые у вас есть, и выберите тот, который кажется вам наиболее подходящим. Документируйте этот выбор и почему вы выбрали именно этот, а не альтернативы. Это дает большую ценность для сопровождающих, чем любой другой источник: вы документируете альтернативы и почему вы их не выбрали, вы исследуете, что будет работать для вас, и выбрали один.
Программная инженерия не сложна, просто сейчас кажется модным просто делать сначала, а потом думать, без правильных рассуждений почему можно было бы сделать это так, а не другой путь.
Удачи:)