4 Comments

  1. 杨雪鸿

    个人也比较支持subdomain与bounded context是1:n的关系,简单的subdomain可以通过一个bounded context,也就是1:1关系(前提是bounded context里的业务术语不能冲突)。
    针对作者提到Alberto Brandolini和Vernon的N:N和1:1,个人看法如下:
    Alberto Brandolini犯了一个错误,就是把具体物体和角色混在一起。
    而Vernon更多是角度问题,站在bounded context看,bounded context与subdomain自然就是1:1了,不然就违背了统一语言;反过来就不一定成立

    • TWInsights TWInsights

      在讨论对应关系之前,还是一定要明确问题和解决方案,问题显然在前,有了问题咱们才谈解决方案。从这个视角出发,一个问题对应一个解决方案显然是最理想的。当然我们知道这样的解决方案很脆弱,很难相应问题的一点变化(或者前期问题认知不足)。1:N算是一种综合考虑,这也比较好理解,逻辑仍然是简单的。然而事实上我们知道复杂的现实并不会因为我们希望简单而简化。比如我们在服务化架构的时候时候,我们会有意在不同服务中“冗余”(重复)实现一个解决方案。售前和销售服务有可能都实现一个轻量级的客户关系。这种刻意的冗余有可能是考虑了不同团队实现效率,基础设施要求等综合约束决定的。这个时候,如果客户关系是之前分析出的一个BC,就存在于了多个问题subdomain中。这样的情况无法枚举,也是为什么心底我们还是应该有N:N的敬畏(即使我们可能大部分时间是1:1 和1:N)

  2. Eric

    “比如“产品展示”Bounded Context的模型可能服务于产品销售和产品评论两个Subdomain子问题。”,一个Bounded Context如果解决了两个Subdomain子问题,我们认为这是bad smell,推荐的做法是讨论能否继续拆分。

    • TWInsights TWInsights

      这要看这个BC所涉及的约束条件,比如我们可能希望‘产品销售’和‘产品评论’ 两个subdomain最后都能够相对独立的工作,相互之间最好是没有啥共同依赖。这个时候我们可能刻意选择‘产品展示’重复实现。特别是在云时代,我们会认为‘重复’并不一定是一件坏事情,刻意的重复可能也是更好利用云特性的一种形式。

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据