2009-09-16 2 views
2

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

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

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

alt text http://img190.imageshack.us/img190/340/databasex.png

домен Модели

alt text http://img24.imageshack.us/img24/8859/classesy.png

+0

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

+0

Я думаю, что этот вопрос можно было бы переименовать в «Modeling recipes domain» или что-то в этом роде. Дизайн модели домена слишком общий. – JuanZe

ответ

3

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

Я думаю, что модели нужны следующие концепции: Рецепт, Ингредиент, Мера и рецептПодготовка.

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

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

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

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

+0

Я согласен, что наличие RecipeIngredient неудобно в модели домена и в основном заканчивается как отображение базы данных 1: 1. –

2

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

Затем измените список рецептов. Ингредиенты, чтобы содержать объекты RecipeIngredient. Наконец, удалите количество из класса Ingredient.

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

+1

Пуристы также сказали бы, что модель домена обычно содержит некоторую форму поведения :-) –

+1

Я бы предложил переименовать RecipeIngredient в «MeasuredIngredient» или «IngredientMeasurement» - то, что описывает природу объекта entity/value. –

0

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

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

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

0

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

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

Смежные вопросы