Question

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

用例是：

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.)

（注册有注册号，ORder编号以供参考，以及课程名称，日期，地点）

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

我将Sales Order视为单独的有界上下文，将Registration & Reservation Bounded Context视为另一个

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

Answer 1

严格来说，有限的上下文只受到泛在语言的使用的限制 - 也就是说，当你发现当被不同的人使用时具有略微不同含义的相同单词时，你会得到一个暗示你需要一个新的有界上下文或者在不同的时间。

在这种情况下，值得探索天气或不是注册＆＃39;在记录客户订单的销售人员的背景下，与在课程中预留场所的人员的上下文中的注册一样，同样的事情。

并且同样的事情我不是指同一个注册，我的意思是 - 在每种情况下，它的行为方式是否相同？相同的属性是否重要？

如果答案是肯定的 - 那么也许你真的在看同一个有界的背景。但是，您也可能在不同的有界情境中查看以不同方式表示的相同事物。

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

在销售订单上下文中，您可以准确地为注册建模，以使其成为订单的一部分。
在注册＆amp;预订上下文你可以准确地建立一个注册模型，以确定它是如何建模的，以保留场所并确认出勤（我猜）。

只要您选择一种唯一标识注册的方式，允许您关联两个上下文中的注册 - 以及一个集成策略（例如REST API或异步消息传递），它允许您协调跨越上下文的长时间运行的工作流 - 又名saga，这完全没问题。

BDD / DDD：跨越边界的特征文件

1 个答案: