【问题标题】:DDD bounded context service vs database integrationDDD 有界上下文服务与数据库集成
【发布时间】:2018-11-28 14:12:44
【问题描述】:

2 个有界上下文,第一个是“产品目录”,第二个是“营销”。

营销环境取决于产品目录。

营销需要产品目录中的特定数据。我在两种方法之间犹豫不决:

1 - 将数据保存在产品目录中,在产品目录中创建一个服务接口,用于查询特定营销用例的数据。

2- 有一个从产品目录数据库中查询数据的流程,并且只将所需的信息(加上所需的任何模型翻译)传输到营销数据库中。

请注意,营销环境实际上并不需要目录中的实时新鲜数据,我现在也不想解决性能问题。

我喜欢第一个选项,因为它看起来更简单,但我不喜欢它,因为我不确定专门为另一个上下文用例设计服务是否真的是一个好习惯? 在我看来,这就像将营销的上下文逻辑泄漏到产品目录逻辑中一样,我担心为许多其他依赖上下文和用例增加服务。

【问题讨论】:

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


    【解决方案1】:

    产品目录 (PC) 位于上游 (US),营销 (M) 位于下游 (DS)。

    如果我没有误解你,基本上你是在问你是否应该进行同步集成(选项 1)或异步(2)。

    既然你说 M 不需要来自 PC 的实时数据,也许我应该去异步集成。但我不会通过数据库集成来做到这一点,而是通过事件:

    每次数据发生变化时,美国上下文 (PC) 都会发布事件(例如 ProductWasCreated),而 DS 上下文 (M) 会订阅它们并做出反应(将产品插入其数据库中)。

    关于方法(1),我认为PC提供M需要的服务没有问题。服务必须满足客户的需求,有界上下文不会提供没有人想要的东西。无论如何,这一切都取决于团队之间的关系(客户/供应商、合作伙伴......)

    您应该查看不同类型的上下文映射(例如,在 Vauhgn Vernon 的红皮书中)。

    【讨论】:

      猜你喜欢
      • 2016-10-15
      • 2013-11-27
      • 1970-01-01
      • 2021-02-23
      • 2015-08-04
      • 2015-05-28
      • 1970-01-01
      • 2014-07-07
      • 2015-04-23
      相关资源
      最近更新 更多