domain-driven-design - 在领域驱动设计中实现限界上下文

Question

我最近决定学习领域驱动设计。我想出了一个假设的应用程序并尝试为其设计架构。它是一个简单的 Poing-Of-Sale 应用程序，具有限界上下文销售和库存。这就是我在为这些限界上下文实现代码时有两个相互冲突的设计的地方。

设计#1:

• 与库存有关的任何事物都属于库存限界上下文。

• 如果收到销售订单，请求最初进入销售限界上下文，然后是进行销售的步骤之一，您必须检查库存以查看商品是否可用。在这种情况下，您请求库存上下文(但是这是在系统内完成的)。库存上下文将检查数据库并以可用性确认作为响应。这样，任何其他需要任何类型的库存涉及逻辑的限界上下文都将使用此限界上下文来实现它。代码已封装，可以使用。

设计#2:

• 限界上下文的划分严格按照其操作上下文中的业务级别划分。

• 如果销售订单进入销售限界上下文，它应该包含与销售有关的所有代码逻辑。它将通过服务检查数据库是否有库存，然后从库存中删除该项目，再次通过服务在数据库中记录销售额，如果需要，则向管理员发送销售通知电子邮件。与销售有关的所有事情都将在这个有界上下文中发生。一旦销售完成，它可以触发一个事件销售，库存上下文将听取这个以检查数据库中的库存，看看是否需要进行新购买以引入新库存，因为它与操作相关到业务层面的库存。

我只是想了解这种系统中的领域驱动设计方法。谢谢。

=================================

经过一番思考，这是对原始问题的补充。

假设您的企业需要进行运输。是由于进行销售(销售限界上下文)还是由于保修更换(支持限界上下文)。如果根据情况运输本身很复杂怎么办。对于某些产品或送货地址，您需要自行决定运送或通过使用网络服务的第三方运送公司运送。 “shipping”是否应该有自己的 Shipping Bounded Context？或者它只是嵌入在销售限界上下文和支持限界上下文中的另一个领域逻辑？这都在简单零售店域的情况下。

Answer 1

我的 2 美分...设计 #2 似乎更好，因为设计 #1 应该会引导您进入分布式系统。您不需要分布式系统。在获得业务之前，您不应该考虑存储或表。只考虑业务，当你得到它时，考虑如何让你的 BC 在完全隔离的情况下运行(离线模式与分布式模式)。如果数据缺失，请考虑使用领域事件将此知识传播到您的 BC。