DDD有界上下文服务与数据库集成

时间:2018-11-28 14:12:44

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

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

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

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

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

2-有一个过程可以查询产品目录数据库中的数据,并且仅将所需的信息(以及进行所需的任何模型翻译)传输到营销数据库中。

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

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

1 个答案:

答案 0 :(得分:1)

产品目录(PC)位于上游(美国),市场营销(M)位于下游(DS)。

如果我不误会您,基本上您是在问应该进行同步集成(选项1)还是异步(2)。

由于您说M不需要PC的实时数据,所以也许我应该进行异步集成。但是我不会通过数据库集成来实现,但是会发生事件:

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

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

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