Domain driven design BDD/DDD：跨越边界的要素文件

我正在开发一个处理短期课程的应用程序，基本上客户可以注册或预订课程，购买课程所需的书籍或其他材料（杂项）

用例是：

As a sales person
I need to record customers orders (reservation, registration, miscellaneous)
So that I can keep track of each slots needed

但在与领域专家讨论时

Lets say the customer orders
1 English Course Registration which costs 499
1 Translation Course Registration which costs 899
1 Reservation for HR Resource 899
1 Book which cost 250

Then
I should have
1 Order containing all the 4 items (2 course, 1 reservation, 1 book) including the prices.

1 course registration for English  (includes the Order No., unique Registration No.)
1 course registration for Translation (includes the Order No., unique Registration No.)
1 reservation form. (includes the Order No. and unique Reservation No.)

（注册号、订单号、课程名称、日期、地点供参考）

请注意，我们允许部分付款。

我将

销售订单

视为单独的有界上下文，将

注册和预订有界上下文

视为另一个上下文

---

但是基于跨越边界的用例，这是否意味着这两个上下文应该合并？

严格地说，有边界的上下文只受无处不在的语言的使用的限制-即，当你发现同一个词被不同的人或在不同的时间使用时，意思略有不同时，你会得到一个提示，你需要一个新的有界上下文

在这种情况下，值得探讨天气与否。销售人员记录客户订单时的“注册”与预订课程时的注册是一样的

我所说的同一件事并不是指完全相同的注册，我的意思是——在每种情况下，它的行为方式是否相同？相同的属性重要吗

如果答案是肯定的，那么你可能真的在看同一个有界上下文。但也有可能你在不同的有界上下文中以不同的方式看待同一事物

这实际上是使用单独的有界上下文最自由的部分：

在销售订单上下文中，您可以精确地对注册建模，以使其成为订单的一部分

在注册和预订上下文中，您可以准确地对注册建模，以确定预订名额和确认出勤（我假设）

---

只要您选择一种唯一标识注册的方法，它允许您在两个上下文中关联注册，以及一种集成策略（例如REST API或异步消息传递），它允许您协调跨上下文的长时间运行的工作流，也就是a，那就很好了

感谢您指出BC应该是UL的边界。我认为销售部分就像是我们在不同的有界环境下销售的东西的聚合器，所以我们只需要物品的描述和价格。如预订课程列表BC（我们提供的课程列表，没有具体日期，只有标准价格和持续时间）、注册课程日历BC（预定在特定日期和地点的课程）以及其他可销售项目，如书籍等（杂项）。在注册BC时，我们不再需要价格，甚至不需要其他物品。因为我们公司很小，对我来说，最具挑战性的是，我们公司的一个人在多个部门工作，扮演着不同的角色，这需要不同的数据，这让我有点困惑，无论我们是在同一个环境中还是已经在讨论另一个环境。