一切似乎都是聚合根 [英] Everything seems to be an Aggregate Root

问题描述

我想为一家餐馆的菜单组成建模。我围绕三个概念创建了一个非常小的绑定上下文：菜单，类别，产品。

I want to model menus composition in a Restaurant. I've created a very small Bounded Context around just 3 concepts: Menu, Category, Product.

菜单由不同的产品以及每个菜单中的每个产品组成放置在某个类别下（例如，类别进入者，第一道菜，第二道菜，甜点…）。

Menus are composed of different Products and every product in each menu is placed under a certain Category (a category is for example, "entrants", "1st course", "2nd course", "dessert"…).

问题在于，对我而言，一切似乎都像一个实体。

The problem is that everything seems like an Entity to me.

例如，当删除菜单时，没有产品或类别被删除。当其他3个概念出现同样的情况。

For example, when a Menu is deleted, no Products or Categories are deleted. The same happens when the other 3 concepts.

关于UI，菜单将像层次结构一样被消费：

Regarding the UI, Menus will be consumed like a hierarchy:

Menu1
    Category1
        Product1
        Product2
    Category2
        Product3
        Product4

我想知道如何对此建模。我应该将它们设为3个总计吗？那么，如何像上面的层次结构一样使用菜单才能被使用？

I'm wondering how to model this. Should I make them 3 Aggregates? Then, how should a compose a Menu in order to be consumed like the hierarchy above?

谢谢。

推荐答案

我认为您正在尝试将所有内容都放入DDD中，而不是仅仅通过研究真实世界来关注此域的简单性。请让我先谈谈简单的面向对象方法，然后让我们谈谈如何在DDD中查看它。
因此，您想要菜单，以便餐厅顾客可以看着他们并选择他们想要吃的东西。假设现在只有1个
餐厅经理应该能够创建此菜单并随时更改菜单。
这是我们的第一个用例

I think you are trying to make too much effort putting everything into DDD instead of making focus of the simplicity about this domain by just looking into the "real world. Please let me first go with an plain OO approach and just then let's talk about how to see it with DDD. So you wanna have Menus so restaurant customers can look at them and choose whatever they want to eat. Let's suppose at the moment there will be just 1 menu for lunch, dinner, every weekday. The restaurant manager should be able to create this Menu and change it whenever he wants to. This is our first use case

menu = new Menu("monday lunch", starters, mainEntrees, desserts, drinks);

其中每个参数都是值对象列表（乍一看）
只需看一下r在整个世界中，菜单是对您在餐馆中可以买到的食物的描述，这些描述是不可变的对象（价值对象），到目前为止，我们不需要任何其他东西。
目前，我们只有一个聚合根，即Menu。它具有全局标识，并且将一组对象分组并且具有不变性。我将使用哪种课程来模拟主菜，甜点？字符串...到目前为止，字符串的一个实例就足够了。
菜单呢？我们可以有许多菜单，一个菜单用于星期一，一个菜单用于星期二，一个菜单在星期五晚上，依此类推，每个菜单都有其自己的全局标识，因此我们可以肯定有MenuRepository。
餐厅经理是否要添加新的甜点呢？

where each of those parameters are lists of value objects (at first sight). Just take a look at the real world, a menu is a description of the food you can get in a restaurant, those descriptions are inmutable objects (value objects) so so far we do not need anything else. At this moment we have only one aggregate root that is Menu. It has global identity and groups a cluster of objects and has invariant. What class would I use to model an entree, dessert? String... an instance of String is enough so far. What about the menu? We could have many Menus, one for monday, one for tuesday, one for friday night and so on, each having its own global identity so we have for sure the MenuRepository. What about if the restaurant manager wants to add a new dessert?

menu = menuRepository.get(menuId);
menu.add(aDessert); 

就足够了。
到目前为止，我们有一个Menu聚合根及其存储库。
我想这就是您要的。

is enough. So far we have one Menu aggregate root and its repository. I think this is what you asked.

但是，我认为您错过了这个价格。菜单上的每一行都会有价格，如果午餐或晚餐，菜单上不同的两个相同的甜点的价格可能也不同，因此，更现实的方法似乎是：

However, I think you missed the price. Each line on the menu would have prices, and two same desserts on different menus may have different prices if its lunch or dinner, so a more realistic approach seems to be:

menu = new Menu("monday lunch", starters, mainEntrees, desserts, drinks);

其中，起动器，mainEntrees，甜点，饮料是MenuLine类型的集合。
现在，如果顾客告诉服务生要带他吃东西怎么办？需要创建一个新订单以保持客户要求的进度，以便以后创建发票。
此订单需要知道客户要的食物，我的意思是客户要订购的菜单项。到目前为止，我们正在使用价值对象对甜点，饮料等进行建模。现在，我们应该为客户可以选择的那些选项提供某种形式或标识符，以便我们在订单上下文（例如订单）中使用某些唯一标识符。这是我们确定需要另一个聚合根（您称为产品）的地方。我宁愿称它为Food或类似的东西。
因此，当餐厅经理决定让餐厅提供新食物时，系统将为

where starters, mainEntrees, desserts, drinks are a collection of type MenuLine. Now what happens if the customer tells the waiter to bring him something to eat? a new order needs to be created to keep progress of what the customer asks in order to create an invoice later. this order needs to know what food the customer asks, I mean what menu item the customer orders. So far we are using value objects to model the desserts, drinks, etc. Right now we should give some form or identifier to those options the customer can choose in order for us to have some unique identifier to use in order contexts such as orders. This is where we determine we need another Aggregate Root (the one you called Product). I would rather call it Food or something like that. So when the restaurant manager decides to let the restaurant offer a new food the system would be

food = new Food("sushi");
foodRepository.add(food);

然后我们的经理想要将寿司添加到星期一晚上的菜单中

and then we the manager wants to add sushi to the menu of monday night

food = foodRepository.getBy(foodId);
menu = menuRepository.findByCriteria(mondayNight)
menu.addAt(food, tenDollars);

菜单的作用是

addAt(food, tenDollars) {
mainEntrees.add(new MenuItem(food.id, food.description, tenDollars)
}

由于沃农·弗农在书中所说的话，我们不希望菜单中保留对食物总量根的引用。

we do not want the Menu to hold a reference to the Food aggregate root because of what vaughn vernon said in its book.

希望对您有所帮助。

Menu {
List starters;
List entrees;
List desserts;
List drinks;
}

希望有帮助。

干杯，
塞巴斯蒂安

Cheers, Sebastian

这篇关于一切似乎都是聚合根的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！