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

[Nathan Lenz]

Sebastian Kurfürst wrote:
> Hi Nathan,
>
> From your domain model, I'd say entity. Because the identity of the
> recipe stays the same, even if some properties change (like if a rating
> or review is added). Additionally your recipes _need_ some kind of
> external identity (even if this is just the UID in the database), as you
> need to link to them I guess :)
> 
> Furthermore, you are _not_ allowed to change a ValueObject after its
> creation. This is +1 for _entity_.
> 
> Additionally, only _entities_ are findable by Repositories, as only
> Entities have an Aggregate Root.

Thanks Sebastian, I appreciate the feedback.  It is helpful to think
through this as _my_ domain model where I can do it how I want.

Also, the fact that Value Objects are not editable is very helpful, I
didn't remember that.


> If there isn't any semantics associated with these units for now, you
> could f.e. just use a simple list of named integer constants.
> 
> For me, the _Measure_ is a Value Object. This has a quantity and a unit.
> As the unit is a fixed list, I'd use a fixed list here as well.
> 
>> 	B. Yet to be implemented Single table inheritance.  Ala
>> "static_info_tables"  Only problem with this one is that it's not
>> implemented yet. :)
> I'm not sure how you want to apply this to your use case, but maybe I'm
> overlooking something ;-)
> 
> Jochen already has some prototypical code working for that, so I'd
> expect this to come to trunk in the coming months :)

I could create a table called static_info_units_measure and fill it with
all the standard units of measure.  I wouldn't personally need
internationalization, but it could be there.

Then load the units I need into the model somehow.  Maybe this is where
I would use Single table inheritance, if not.. then I don't really
understand it, but thats ok. :)  I could create a service that queried
the list and returned the appropriate units of measure for the context.

A small list of named integer constants would be easier to code.

> 
>> 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.
> Is the website an information of the recipe, or is it rather a meta-data
> which f.e. decides on which website the recipe will be shown?

It is meta-data which f.e. uses to decide on which website the recipe
will be shown.  Should meta data be part of a domain or put somewhere else?

I see that "hidden" isn't in the domain for "blog example" but I can
hide blogs in the List module and it is a part of the SQL table.


> 
> If it's for the former case, I'd include the website into your recipe,
> because the websites of the recipe are a concept of _your_ domain I'd
> say... Or if you want to separate this somehow, then move the "website"
> property to a subclass of "recipe" (f.e. OnlineRecipe or the like) - and
> make the "Website" a part of your domain model.


Maybe I'll just do it the way it's done in my piBase extension. I just
want to make sure there isn't a more proper way to do it.

"web_instance" => Array (		
	"exclude" => 1,		
	"label" => "Web Instance",		
	"config" => Array (
		"type" => "select",	
		"foreign_table" => "pages",	
		"foreign_table_where" => "AND pid=0 AND doktype=1 ORDER BY pages.uid",	
		"size" => 5,	
		"minitems" => 0,	
		"MM" => "tx_myext_recipe_web_instance_mm",
	)
),



> 
> Hope this helps!
> 
> Merry Christmas :-)

Very much so,
Merry Christmas to you too!

--Nathan