Проектирование доменной модели

Question

Как бы вы создали модель домена для этого простого примера? Рецепт может иметь много ингредиентов, а ингредиент может быть использован во многих рецептах. Сколько каждого ингредиента, используемого в каждом рецепте, также хранится. Я разработал следующие три таблицы базы данных для хранения этих данных и взаимосвязей.

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

Таблицы базы данных

альтернативный текст http://img190.imageshack.us/img190/340/databasex.png

Модель предметной области

альтернативный текст http://img24.imageshack.us/img24/8859/classesy.png

Answer 1

Если вы пытаетесь сделать доменное проектирование, не начинайте с таблиц. Разработайте сначала концептуальную модель, которая отражает ваш основной домен. Я согласен с ndp: RecipeIngredient - это немного неловкое имя / концепция с точки зрения DDD.

Я думаю, что модель нуждается в следующих понятиях: рецепт, ингредиент, мера и подготовка рецепта.

Рецепт - это совокупность ингредиентов. Каждому Ингредиенту, принадлежащему к Рецепту, необходима Мера, связанная с ним, как спецификация для приготовления. Также вам нужно смоделировать RecipePreperation, чтобы связать фактическое количество каждого ингредиента, используемого во время определенной подготовки рецепта.

Мера состоит из единицы и количества (например, 2 чашки, 0,5 унции, 250 г, 2 столовые ложки ...).

Я вижу здесь две разные вещи, которые могут быть смешаны во время анализа и должны быть разделены: рецепт / ингредиент / мера в качестве спецификации для приготовления чего-либо (один экземпляр для каждого рецепта) и рецепт приготовления / ингредиент / мера в качестве конкретного подготовка одного рецепта, сделанного конкретным человеком в определенный момент, и может быть применена другая мера (все ингредиенты удвоены, потому что спецификация рецепта для двух тарелок и у вас четыре гостя ... что-то в этом роде).

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

Answer 2

В вашей доменной модели создайте класс RecipeIngredient, содержащий ссылку на конкретный ингредиент и количество.

Затем измените список Recipe.Ingredients, чтобы он содержал объекты RecipeIngredient. В конце удалите количество из класса ингредиентов.

Просто совет: большинство разработчиков пуристских доменов сказали бы, что вам следует сначала создать модель своего домена, а не заниматься базой данных намного позже.

Answer 3

Я думаю, что вы, ребята, все потерялись. Оригинальный плакат имел правильный импульс, но шел по неправильному пути. На самом деле, таблица отображений, которую он показывает с использованием старой эвристики Риля (объединяющей имена отношений l и r), похоже, учитывает тот факт, что это отображение многие ко многим. Но на самом деле происходит то, что вам нужен класс role (подход Coad's Domain Modeling часто их использовал). Но вот в чем дело: это то, что Ингредиент уже есть! Отсутствующая абстракция здесь открывает банку с червями: это то, что добавляется. Можно утверждать, что это будет базовый класс, например, Пища (поскольку мы буквально по определению не можем добавить в рецепт несъедобные вещи), но тогда вы несете бремя учета всех продуктов питания, или вы можете просто назвать их.

Итак, правильная модель, которую я считаю, состоит в том, что Рецепт содержит ингредиенты, которые содержат определенное количество определенной пищи.

Answer 4

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

По мере роста вашей модели вам, несомненно, потребуется добавить сюда больше данных. Например, как вы устанавливаете порядок ингредиентов в рецепте?

RecipeIngredient - это немного неуклюжее имя (и концепция) с точки зрения доменного дизайна. Возможно, вам удастся придумать разные имена, которые будут лучше. Но в целом это необходимая деталь реализации. Извините, у меня нет книги DDD Эвана, чтобы предоставить справочную информацию.