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