【问题标题】:How can i create two aggregates in different bounded contexts?如何在不同的有界上下文中创建两个聚合?
【发布时间】:2018-07-12 10:50:19
【问题描述】:

关于集成有界上下文的问题。 例如。我在indentity BC 中有organization AR。和courier service ARlogistics BC它们必须连接。

organization AR 包括:

  • 组织 ID
  • 姓名
  • 税码
  • 法定地址
  • ...

courier service AR 包括:

  • CourierServiceId
  • 姓名
  • TransportationPriority
  • 评分
  • ...

客户在一个请求中发送所有这些信息(姓名、税码、法律地址、TransportationPriority、评级)。

问题:

  1. 我应该在哪个应用程序中提交创建两个 AR 的请求?
  2. 我应该如何创建两个 AR?在第一个 BC 中创建第一个 AR 后,我应该如何从第二个 BC 创建第二个 AR?

我遇到的问题:

起初我想在创建organization AR 时发布域事件以通知logistics BC 并创建courier service AR但是当我在第一个 BC 中发布域事件时,我必须使用语言概念作为 TransportationPriority, Rating(需要在第二个 BC 中创建 AR)。但这种语言概念并不属于公元前。但是它们被用于其中。据我所知这是错误的。

那么我该如何解决我的问题呢?对不起,我的英语不好。非常感谢。

【问题讨论】:

    标签: domain-driven-design bounded-contexts dddd


    【解决方案1】:

    为什么“它们必须连接”?据我了解,您可以拥有一个带有多个 CourServAR 的 OrgAR。在这里可以做的事情如下:

    • 用户进入他放置此信息的页面(您写道,所有数据都集中在一起,因此应该使用表单或类似的东西来完成)
    • 他一到那里,我就给了他几个 ID(在 Udi Dahan 的某个帖子中,我现在找不到)
    • 使用此 ID(用于 OrganizationId 和 CourierServiceId),您可以将这两个命令发送到不同的域,而无需使用共享他们不知道/必须使用的数据的事件
      • 当然可能是存储一个 AR 出错了,因此您需要一种方法来验证数据完整性(使用作业或类似的东西 - 然后您必须通知用户在此过程中出现问题)

    要获得 ID,您可能必须编写两个服务,为 OrgAR 和 CourServAR 提供下一个有用的 ID。

    无论如何,这两个 AR 绑定在一起并且您必须将它们存储在一起这一事实在我的大脑中发出了警报。

    其实我会做的是:

    • 确定用户必须真正存储的内容(OrgAR 还是 CourServAR?例如,我采用 OrgAR)
    • 有了这个,创建一个表单来存储 OrgAR
    • 然后,给他存储 CourServAR 的机会
      • 第二个 AR 已经有一个指向第一个的链接(因为我有它的 ID),我现在需要的是一个命令(在 OrgBC 中),上面写着“assignCourServtoOrg”,它只是绑定了 OrgAR 中的两个 ID

    【讨论】:

    • 谢谢!请告诉我,来自另一个有界上下文的全局 ID 是否违反了上下文中普遍存在的语言的规则?它是否必须命名与当地上下文中普遍存在的语言相对应? “assignCourServtoOrg”和“CourierServiceId”对于 OrgAR 来说很奇怪。不是吗?
    • 我认为没有。如果您不使用他们的 ID,您如何在 BC 实体之间共享“链接”?如果您的域需要此操作,请在不与 BC 重叠的情况下对其进行建模。顺便说一句,为什么需要“assignCourServToOrg” snd CourierServiceId?第二个是什么意思?在我看来,您只需要一项服务;在存储第二个实体后,它作用于(反应,更好)第一个实体,属于不同的 BC 并将其绑定到另一个。
    猜你喜欢
    • 1970-01-01
    • 2017-08-25
    • 2023-04-03
    • 1970-01-01
    • 2021-07-05
    • 2019-11-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多