DDD.共享内核?还是纯事件驱动的微服务? [英] DDD. Shared kernel? Or pure event-driven microservices?

问题描述

我正在将我的系统划分为(至少)两个有界上下文:研究设计和调查计划.

I'm breaking my system into (at least) two bounded-contexts: study-design and survey-planning.

在研究设计的背景下，有一个名为主题"(面试的潜在主题)的概念.我们还维护该域中受试者与人群之间的关联.

There's a concept named "subject" (potential subject for interviewing) in the study-design context. We also maintain associations between subjects and populations in that domain.

现在，在调查计划中，我们还需要有关该受试者的(一些)信息(例如:如果事先知道该受试者所属的人群，则用于计划一次探访，甚至是预期的调查表选择)

Now, in the survey-planning, we also need (some) information about the subject (for example: for planning a visit, or even for anticipated selection of questionnaire, in case the population the subject belongs to is known beforehand).

因此，在两种情况下我都需要该主题".

So, I need that "subject" in both contexts.

我应该选择哪种方法?如Eric Evans DDD所述，具有共享内核吗?我不介意(至少到目前为止)让两个上下文共享同一个数据库.

What approach should I pick? Having a shared kernel, as explained in Eric Evans DDD book? I don't mind (at least for now) having the two contexts sharing the same database.

或者...我应该去纯粹的微服务吗?意思是:这两个不能/不应该共享数据库...，在这种情况下，我可能不得不通过事件传递来进行镜像/复制路由:

Or... should I go pure microservice? Meaning: those two can't / shouldn't share database..., and in that case I might have to go the mirroring / duplicating route through event passing: https://www.infoq.com/news/2014/11/sharing-data-bounded-contexts

在上述情况下，有谁想到哪个更好?

Any thoughts on which one is better, for the above situation?

谢谢！

推荐答案

微服务的上下文是分布式系统.在任何其他情况下，这可能都太过分了.共享内核最终将分裂.通常就是这种情况.您可以从它开始.没有错.但是，它不会停留在那里.

The context for microservices is distributed systems. In any other situation it would probably be overkill. Shared kernel will eventually split. That is usually the case. You may start from it. Nothing wrong with that. However, it will not stay there.

这篇关于DDD.共享内核?还是纯事件驱动的微服务?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！