【发布时间】：2016-01-02 08:34:33
【问题描述】：
我最近决定学习领域驱动设计。我想出了一个假设的应用程序，并尝试为它设计架构。这是一个简单的 Poing-Of-Sale 应用程序，具有限界上下文 Sales 和 Inventory。这就是我在为这些有界上下文实现代码时有两种冲突设计的地方。
设计#1：
与库存有关的任何事物都属于库存有界上下文。
如果收到销售订单，请求最初进入销售有界上下文，然后是进行销售的步骤之一，您必须检查库存以查看该项目是否可用。在这种情况下，您请求库存上下文（但这是在系统内完成的）。库存上下文将检查数据库并回复可用性确认。这样，需要任何类型的库存涉及逻辑的任何其他有界上下文都将使用此有界上下文来实现它。代码已封装，可以运行。
设计#2：
有界上下文的划分严格按照业务级别划分在其操作上下文中。
如果一个销售订单进入并达到销售有界上下文，它应该包含与销售有关的所有代码逻辑。它会通过服务检查数据库是否有库存，然后从库存中删除该项目，再次通过服务将销售记录在数据库中，如果需要，向管理员发送销售通知电子邮件。与销售有关的所有事情都将在这个有限的上下文中发生。一旦进行了销售，它可能会触发一个事件 sale made，并且库存上下文会侦听此事件以检查数据库中的库存，查看是否需要进行新购买以引入新库存，因为它与操作相关到业务层面的库存。
我只是想了解这种系统中的领域驱动设计方法是什么。谢谢。
==================================
经过一番思考，这是原版的附加问题。
假设您的企业需要运送。无论是由于进行销售（Sales Bounded Context）还是由于保修更换（Support Bounded Context）。如果运输本身根据情况而复杂怎么办。如果某些产品或送货地址需要您自己决定或通过某些使用网络服务的第三方运输公司发货。 “运输”是否值得拥有自己的运输有界上下文？或者它只是嵌入在销售有界上下文和支持有界上下文中的另一个域逻辑？这都是在简单的零售商店域的情况下。
【问题讨论】：
-
我不认为它是重复的，因为我不只是想知道参考数据。就我的运输问题而言，我试图确定在什么时候将运输作为单独的上下文对您有意义。或者甚至有单独的上下文是否有意义？作为一个企业，你究竟在做什么，只是“运输”它变成了一个“有界”的上下文？
-
限界上下文与子域的概念有关。当您的组织有单独的业务流程并且通常有专门的团队负责相关职能领域时，您就有了一个子域。见gorodinski.com/blog/2013/04/29/…jefclaes.be/2014/02/strategic-ddd-in-nutshell.html
-
我建议您为此提出一个新问题，因为最初的 Q 似乎假定存在多个 BC 作为给定的。
-
DDD 在家里很难练习，因为你需要商务人士。没有商务人士，您将无法了解重要或不重要的内容。此外，stackoverflow 并不总是提倡“经验反馈”。我建议您在 google+ 社区或 LinkedIn 上询问，以听取现实生活中的 DDD 从业者的意见。