[TYPO3-mvc] DDD question about a Recipe model.

[Nathan Lenz]

I am modeling a Recipe roughly based on the hRecipe microformat
http://microformats.org/wiki/hrecipe

A Recipe has a list of "Ingredient groups".
Recipe example: "Chocolate Cake"

An Ingredient group contains a name and a set of Ingredients. Ingredient
Groups are for grouping lists of ingredients for different parts of the
Recipe: Frosting, Cake, Filling.  I think this could use a better name,
but haven't thought of it yet.

An Ingredient:
name: All Purpose White Flour
Measure: (quantity: 2, Unit: (name: cups, symbol: c, type: volume))
Preparation: sifted

Ingredient contains a name, Measure and Preparation.
Measure contains a quantity and a Unit.
Unit contains a name and symbol and type (each, volume, weight)
Preparation contains a name and description.


I have a handful of questions about this model:

1. Should Recipe be a Value Object or an Entity?  I chose Entity because
a recipe will have ratings and reviews.  However, in real life a Recipe
is nothing more than what it is.  If you change anything about it you
get a new recipe.  This would imply that it is a Value Object.



2. Can Value Objects without real identities get ratings, reviews,
etc... on the website?  If someone rates a recipe for "Chocolate Cakee"
"4 stars" and then I fix the name, I have created a new Recipe.  Would
the rating be transferred?



3. What is the best practice for modeling Unit?  Units are standard
things that shouldn't change.  I'd like the User Interface for choosing
a measure to limit it to a defined list.  I see two options:

	A. Create a Unit Model, Repository, etc.. Build CRUD forms for Units.
Make one of the views return all Units in a format that creates a select
box.  Then when creating the form for creating new Recipes, it would
call the "all units" view to build the form. My problems with this one:
 It seems way complex just to build a drop down that lists "cups,
tablespoons, teaspoons, ounces, etc.."

	B. Yet to be implemented Single table inheritance.  Ala
"static_info_tables"  Only problem with this one is that it's not
implemented yet. :)

	C. Any I'm overlooking?



4. Where should non-Recipe domain fields go?  Currently our recipe
editor can assign each recipe to a handful of websites using a "Web
Instance" multi-select that is build based on a query of our sys_domains
table.  A real recipe doesn't have any concept of different websites.


Thank you for considering my questions.
--Nathan