两部分问题
我有一个具有的产品集合；
价格
包装选项
产品说明
产品图片
等等
我已经为一个产品存储库建模，并且没有为任何子类创建单独的存储库。所有数据库操作都通过产品存储库处理。
到目前为止，我是否正确理解DDD概念？有时候，我想到的问题是，拥有一个可以说打包选项的存储库，可以通过使用其ID直接从数据库中获取一个打包选项，而不是要求产品存储库在其PackagingOptions集合中找到它并给出给我
第二部分是使用ASP.MVC框架管理编辑创建操作
我目前正在尝试通过产品 Controller 来管理这些产品子集的所有添加编辑删除操作(正确吗？)。
我现在面临的一个挑战是；
如果我通过以下方式编辑产品的特定包装选项
mydomain/product/editpackagingoption/10
我可以访问包装选项的ID
但是我没有自己的产品ID，这迫使我编写查询以首先找到具有此特定包装选项的产品，然后编辑该产品和相关的包装选项。我可以这样做，因为所有包装选项都具有唯一的ID，但是如果我的收藏集没有唯一的ID，则此操作将失败。
感觉很不对劲。
我想到的下一个选项是在url上发送产品和包装选项ID，例如；
mydomain/product/editpackagingoption/3/10
但是我也不确定这是否是一个好的设计。
所以我有点困惑。围绕这一切可能会有根本的误解...
如果您有一个漫长的问题，请帮助我将其汇总，不胜感激。谢谢!
最佳答案
在我看来，这是DDD出现的那些泥泞的事物之一。
在代码中，我将聚合根视为其具有的所有“关系”以及没有聚合根就无法存在的任何实体对象的容器。
例如，让我们以客户->订单-> LineItem->产品示例为例，该示例现在已经被压制到死了。正如我所显示的，在这种情况下，聚合根是客户。也就是说，您并不总是希望通过客户获得订单。您可能要查找特定日期的订单。
顺便说一句，您也不会有没有订单的客户。两者之间存在某种共生关系，因此一个不是另一个的总根。
关键是您不需要通过订单加载客户，但也不一定要通过客户加载订单。
但是，从Order开始，您不太可能只想获取LineItem，并且肯定不会在没有订单的情况下创建它们。为此，订单用作LineItems的网关。 LineItem不需要它们自己的 Controller 或存储库。它们仅存在于Order本身中，因此，它们是Order的一部分(在这种情况下，Order成为聚合根)，并由Order实体进行管理。
但是，LineItem可能与系统内的Product有关系。产品将具有自己的 Controller ，存储库等，因为它们可以存在于聚合根目录之外。
总而言之，我倾向于这样看待它:如果一个实体可以自身存在，那么它应该有一个 Controller 。不能单独存在的实体(在这种情况下为LineItem)应仅由其容器(聚合根)进行管理。
如果我/错在哪里，一些DDD纯粹主义者是否可以纠正我？
关于您问题的第二部分，我需要更多有关您如何设想其他实体工作的详细信息。有了您在此处输入的内容，我可以想象到PackagingOptions与产品相关，并且将成为Product聚合根的一部分。现在，暗示您正在编辑它们，这引出了一个问题，即这是系统中的查找表还是它们的一次性值，因此应将其视为“值对象”？
关于asp.net-mvc - DDD原理和ASP.NET MVC项目设计，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/1338139/