我最近决定学习领域驱动设计。我提出了一个假设的应用程序，并尝试为它设计架构。它是一个简单的Poing-Of-Sale应用程序，具有有界的上下文销售和库存。在为这些有界上下文实现代码时，我有两个相互矛盾的设计。
设计＃1：
与库存有关的任何事情都属于库存限制环境。
如果销售订单进入，请求最初进入销售限额上下文，然后进行销售的其中一个步骤，您必须检查库存以查看该商品是否可用。在这种情况下，您请求清单上下文（但这是在系统内完成的）。清单上下文将检查数据库并回复可用性确认。这样，任何需要任何类型的库存逻辑的其他有界上下文都会使用这个有界的上下文来实现它。代码已封装好，可以使用。
设计＃2：
有限上下文的划分严格来自其业务环境中的业务级别。
如果销售订单进入并达到销售限额上下文，则应包含与销售有关的代码中的所有逻辑。它会检查数据库是否通过服务提供库存，然后从库存中删除该项目，再次通过服务在数据库中记录销售，如果需要，则向管理员发送销售通知电子邮件。只有与销售有关的一切和任何事情都将在这个有限的背景下发生。一旦进行了销售，它就可以触发事件销售，并且库存上下文会听取这个以检查数据库中的库存，看看是否需要进行新的购买以引入新库存，因为它是与操作相关的商业层面的库存。
我只是想了解这种系统中的域驱动设计方法。感谢。
=================================
经过一番思考后，这是对原文的补充问题。
让我们说您的业务需要发货。是否由于进行销售（销售有限上下文）或由于保修更换（支持有界上下文）。如果运输本身很复杂，视情况而定。如果某些产品或送货地址需要您自己决定发货，或者通过某个第三方运输公司使用网络服务。 ＆＃34;运输＆＃34;值得拥有自己的航运有界上下文？或者它只是嵌入在Sales Bounded Context和Support Bounded Context中的另一个域逻辑？这都属于简单的零售店域。
答案 0 :(得分：1)
我的2美分......设计＃2似乎更好，因为设计＃1应该引导您进入分布式系统。您不需要分布式系统。在开始业务之前，您不应该考虑存储或表格。只考虑业务，当你得到它时，考虑如何能够完全隔离你的BC运行（离线模式与分布式模式）。如果缺少数据，请考虑使用域事件将此知识传播到BC。
答案 1 :(得分：-1)
设计＃1是正确的。库存环境应该是唯一决定并知道如何检查库存的环境。可能是库存上下文正在从多个位置进行检查，当新数据仓库联机时，这些内容可能会根据元数据更新而发生变化。在某些时候，零售商可能会决定将所有实体店铺作为数据仓库。
同样，运输也应该是一个背景。上面的注释说我们不应该以分布式系统为目标，但我不明白为什么不提供敏捷性。