有限上下文和共享业务逻辑(DDD)

发布于 2025-02-13 22:40:54 字数 414 浏览 1 评论 0原文

我们正在尝试在工作中应用DDD,我对它们定义有限上下文的方式感到困惑。

他们将有限的环境定义为利益相关者,因此在我们的情况下,我们有客户,卖方,管理员,销售。

他们的论点是,每个有限的上下文都有一个改变的理由(作为人或团体,因此是利益相关者)。

问题是我们正在复制业务规则,因为我们的有限上下文是松散的耦合。

因此,假设我们有退款用例,卖方可以退还客户,而管理员可以代表卖方退还任何客户。 我们定义有限上下文的方式,我们现在正在复制退款业务规则。

我没有更好的处理方法,我是DDD的新手,想对:

  • 有限的环境应该是利益相关者?
  • 商业规则重复是不良设计的指示吗?
  • 我们如何对有限上下文进行建模以更好地设计管理员退款 /卖方退款用例?

PS:这是一个整体应用

We are trying to apply DDD at work, and i'm confused with the way they defined bounded contexts.

They are defining bounded contexts as stakeholders, so in our case we have Customer,Seller, Admin, Sales.

Their argument is, each bounded context has one reason to change (reason as person or a group and thus stakeholders).

The problem is we are duplicating business rules since our bounded contexts are loosely coupled.

So let's say we have a refund use case, Sellers can refund their customers while Admins can refund any customers on behalf of the Seller.
The way we defined our bounded contexts, we are now duplicating the refund business rules.

I don't have a better approach of dealing with this, i'm new to DDD, would like to have some help/clarifications on:

  • Are bounded contexts supposed to be stakeholders ?
  • Is business rules duplication an indication of bad design ?
  • How can we model our bounded contexts to better design Admin refund / Seller refund use cases ?

P.S: it's a monolith app

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

不必了 2025-02-20 22:40:54

我不是DDD-GURU,但我有一些经验,所以我会试一试。

有界的上下文是名称所暗示的,即有限的上下文到特定领域。它具有特定定义明确的语言,专为特定任务而设计。它通常具有代表用例的取消标准化状态的聚集体。

在您的情况下,有限的上下文可能是“退还”或类似的东西,可能会根据“ sellerRefundProcess”的汇总,而实体或实体或仅根据每个用例的价值观。

撰写时,有限上下文应松散耦合。这是将复杂的域分为针对特定任务/用例的更特定域的重要原因。但是,如果您有业务规则,则必须在这些域之间共享,那么是的,毕竟它们并没有那么不同。也许您的域可能会以其他方式分割。

一种更简单的方法是与共享内核组件分享您拥有的共同规则。不是那么干净,但有时是不可避免的。

只是一些想法和想法,值得它的价值。

I'm no DDD-guru but I have some experience with it so I'll give it a shot.

A bounded context is just what the name suggests, a context which is bounded, to a specific domain. It has a specific well-defined language and is designed for specific tasks. It often have aggregates of de-normalized state representing use-cases.

A bounded context in your case may be "RefundHandling" or something like that, with aggregates for perhaps "SellerRefundProcess", and entities or just values for "Seller" etc depending on each use-case.

Bounded contexts should be loosely coupled as you write. That's a big reason for dividing a complex domains into more specific domains focusing on specific tasks/use-cases. But if you have business rules you have to share between these domains, then yes perhaps they are not so different after all. Perhaps your domain could be divided in other ways, if any.

An easier approach would be to share the common rules you have with shared kernel assembly. Not as clean but sometimes it's unavoidable.

Just some thoughts and ideas, for what it's worth.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文