Domain driven design 基于领域驱动设计方法的业务逻辑推理/建模

我试图实现的是开发一个实现DDD方法的应用程序

这个故事听起来可能很傻，但却是一个现实生活中的问题。相信我

业务情况如下：

• 比如说，一家公司专门生产糖果，这些糖果被分发到自己的商店出售
• 这名工匠根据公司一家商店目前陈列的是什么和不是什么，制作不同类型的糖果
• 当一种口味的篮子“消失”时，卖家会用一种不同于商店储藏柜的甜品来替换这种类型的甜品
• 显示器上不应存在重复的味道，显示器上应填充尽可能多的容量，或制造商能够处理的生产量
• 根据需求，糖果从制造商实验室的仓库分配到商店的仓库

假设每个工作人员都可以在公共视图中访问显示器和存储柜。每个工作者（用户）决定自己提供什么。商店显示视图将通过应用程序向潜在客户公开，作为当前正在销售的信息

到目前为止，我已将业务逻辑划分为三个独立的（子？）域，分别是：

• 生产
• 分布
• 出售

当然，每个实体，如糖果、存储、工匠、it存储库等，都分别位于各自的域中

我所关注的问题是：

• 实体（Sweet）从一个域传递到另一个域是否合适

---

• 提供商是否应该能够访问一个域的StorageCabinet并将其内容传递给另一个域

我的推理正确吗？如果我错了或违反了DDD规则，请纠正我

提前谢谢

这个故事听起来可能很傻，但却是一个现实生活中的问题

事实上，这很好。在他最近的一篇文章中，格雷格·杨（Greg Young）指出，“购物车”模型作为一种教学工具是非常糟糕的。他简要指出，有趣的问题在于供应链

实体（Sweet）从一个域传递到另一个域是否合适

不，但描述实体状态的消息（DTO）可能会从一个域传递到另一个域

您希望保持灵活性，在每个域中以不同的方式定义实体；这是识别有界上下文的一部分

---

提供商是否应该能够访问一个域的StorageCabinet并将其内容传递给另一个域

---

可能不是：您的域模型不是存储机柜的记录簿。仔细聆听Greg对的评论。

“访问一个域的StorageCabinet并将其内容传递给另一个域”-你的意思是什么？另一个领域？另一个内阁？StorageCabinet实体不只是在销售子域中吗？@guillaume31:制作糖果后，工匠将其储存在自己实验室的StorageCabinet中，以便供应商知道提取什么并将其交付给每个商店StorageCabinet。供应商属于哪个子域？您可能希望了解有界上下文的概念，它是解决方案空间中子域的具体化，以及使BC相互对话的不同方式。您谈论DDD，但不使用任何战略设计术语，如“有界上下文”或“聚合”。这导致了一些令人担忧的结论。。。