领域模型设计

发布于 2024-08-05 01:39:50 字数 576 浏览 7 评论 0原文

您将如何为这个简单的示例创建域模型? 一个食谱可以有很多成分,并且一种成分可以在很多食谱中使用。 每个食谱中使用的每种成分的数量也被存储。 我设计了以下三个数据库表来存储这些数据和关系。

我现在正在尝试创建一个域模型来表示这一点。我有一个包含两个类的基本示例。 当我考虑创造一种新成分时,我遇到了这个模型的麻烦。 需要有一个没有数量属性的类。 这应该如何建模?

数据库表

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

域模型

替代文本http://img24.imageshack.us/img24/8859/classesy.png

How would you create a domain model for this simple example?
A recipe can have many ingredients and an ingredient can be used in many recipes.
How much of each ingredient used in each recipe is also stored.
I have designed the following three database tables to store this data and the relationships.

I am now trying to create a domain model to represent this. I have a basic example with two classes.
I then ran into trouble with this model when I thought about creating a new ingredient.
There would need to be a class with out the quantity property.
How should this be modeled?

Database Tables

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

Domain Model

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

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

未央 2024-08-12 01:39:50

如果您尝试进行领域驱动设计,请不要从表开始。首先详细阐述反映您的基础领域的概念模型。我同意 ndp 的观点:从 DDD 的角度来看,RecipeIngredient 是一个有点尴尬的名称/概念。

我认为该模型需要以下概念:Recipe、Ingredient、Measure 和 RecipePreparation。

配方是成分的集合。属于配方的每种成分都需要与其关联的测量,作为准备的规范。此外,您还需要对 RecipePreparation 进行建模,以关联特定配方准备过程中使用的每种成分的实际数量。

度量由单位和数量组成(例如 2 杯、0.5 盎司、250 克、2 汤匙...)。

我在这里看到两种不同的东西在分析过程中可以混合,应该分开:食谱/成分/测量作为烹饪某种东西的规范(每个食谱一个实例)和食谱准备/成分/测量作为一个具体的准备食谱,由特定的人在特定的时刻完成,并且可能使用不同的措施(将所有成分加倍,因为食谱规格适用于两个盘子,而您有四个客人......类似的东西)。

您可以更深入地开始建模,例如某些具有一组可交换成分的成分(例如,如果您没有山羊奶酪,请使用马苏里拉奶酪)、收集一组相同类别食谱的食谱、食谱的烹饪时间, ETC。

If you are trying to do domain-driven design don't start with tables. Elaborate first a conceptual model that reflects your underlying domain. I agree with ndp: RecipeIngredient is a bit of an awkward name/concept, from a DDD perspective.

I think the model needs the following concepts: Recipe, Ingredient, Measure and RecipePreparation.

A Recipe is an aggregation of Ingredients. Each Ingredient belonging to a Recipe need a Measure associated to it, as a specification for the preparation. Also you need to model the RecipePreparation to associate the actual quantity of each ingredient used during a specific preparation of the recipe.

A Measure consists of unit and amount (e.g. 2 cups, 0.5 oz, 250 gr, 2 tbsp...).

I see here two different things that could be mixed during analysis and should be kept split: Recipe/Ingredient/Measure as a specification in order to cook something (one instance for each recipe) and RecipePreparation/Ingredient/Measure as a concrete preparation of one recipe, done by a specific person on a specific moment, and may be using different measures (doubled all the ingredients because the recipe specification is for two plates and you have four guests... something like that).

You can go deeper and start modeling things like some ingredients having a set of exchangeable ingredients (e.g. if you don't have goat's cheese use mozzarella), a cookbook that collect a set of recipes of the same category, a cooking time for the recipe, etc.

玩套路吗 2024-08-12 01:39:50

在域模型中创建一个 RecipeIngredient 类,其中包含对特定成分和数量的引用。

然后更改 Recipe.Ingredients 列表以包含 RecipeIngredient 对象。最后从 Ingredient 类中删除 Quantity。

只是提示:大多数纯粹的领域建模者会说您应该首先创建领域模型,直到很久以后才关心数据库。

In your domain model create a RecipeIngredient class containing a reference to a specific Ingredient and a Quantity.

Then change the Recipe.Ingredients list to contain RecipeIngredient objects. Finally remove Quantity from the Ingredient class.

Just a tip: most purist domain modellers would say you should create your domain model first and not concern yourself with the database until much later.

星星的轨迹 2024-08-12 01:39:50

由于连接表中有数据(数量),因此答案是您需要一个类来表示它。 (还有其他替代方案,但不值得考虑。)

随着模型的增长,您无疑需要在此处添加更多数据。例如,如何设置菜谱中配料的顺序?

从领域驱动设计的角度来看,RecipeIngredient 是一个有点尴尬的名称(和概念)。您也许可以想出一些感觉更好的不同名称。但总的来说,这是一个必要的实现细节。抱歉,我手边没有 Evan 的 DDD 书来提供参考。

Since you have data in your join table (quantity), the answer is that you need a class to represent it. (There are other alternatives, but not worth considering.)

As your model grows, you will undoubtedly need to add more data here. For example, how do you set the order of the ingredients in the recipe?

RecipeIngredient is a bit of an awkward name (and concept), from a domain driven design perspective. You may be able to come up with different names that feels better. But in general, this is a necessary implementation detail. Sorry, I don't have the Evan's DDD book handy to provide a reference.

も星光 2024-08-12 01:39:50

我想你们都迷路了。最初的发帖者有正确的冲动,但走错了路。实际上,他使用旧的 Riehl 启发式(结合 l 和 r 关系的名称)显示的映射表似乎正在解决它是多对多映射的事实。但实际情况是,您需要一个角色类(Coad 的领域建模方法大量使用了这些)。但事情是这样的:Ingredient 已经是这样了!不过,这里缺少的抽象会带来麻烦:它是正在添加的东西。有人可能会争辩说,这将是一个基类,例如食物(因为从字面上看,根据定义,我们不能在食谱中添加不可食用的东西),但是这样你就有了计算所有食物的负担,或者你可以只命名它们。

所以我认为正确的模型是食谱包含含有一定量特定食物的成分。

I think you guys are all lost. The original poster had the right impulse, but was taking the wrong route. Actually, the mapping table he shows, using the old Riehl heuristic (combining the names of the l and r relations) seems to be addressing the fact that it's a many-to-many mapping. But what is really happening is that you need a role class here (Coad's Domain Modeling approach used these a lot). Here's the thing though: that's what Ingredient is already! The missing abstraction here opens a can of worms though: it's the thing that's being added. One could argue that that would be a base class, e.g. Food (since we literally, by definition cannot add inedible things to a recipe), but then you have the burden of accounting for all foods, or you can just name them.

So the correct model I think is Recipe contains Ingredients which have some amount of a specific Food.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文