极客时间已完结课程限时免费阅读

08 | 微服务架构模型：几种常见模型的对比和分析

08 | 微服务架构模型：几种常见模型的对比和分析-极客时间

08 | 微服务架构模型：几种常见模型的对比和分析

2019-10-30 欧创新 来自北京
《DDD实战课》
课程介绍

讲述：欧创新

时长16:34大小11.36M

你好，我是欧创新。
在上一讲中我重点介绍了 DDD 分层架构，同时我也提到了微服务架构模型其实还有好多种，不知道你注意到了没？这些架构模型在我们的实际应用中都具有很高的借鉴价值。
那么今天我们就把 DDD 分层架构（详情介绍如有遗忘可回看 [第 07 讲] ）、整洁架构、六边形架构这三种架构模型放到一起，对比分析，看看如何利用好它们，帮助我们设计出高内聚低耦合的中台以及微服务架构。

整洁架构

整洁架构又名“洋葱架构”。为什么叫它洋葱架构？看看下面这张图你就明白了。整洁架构的层就像洋葱片一样，它体现了分层的设计思想。
在整洁架构里，同心圆代表应用软件的不同部分，从里到外依次是领域模型、领域服务、应用服务和最外围的容易变化的内容，比如用户界面和基础设施。
整洁架构最主要的原则是依赖原则，它定义了各层的依赖关系，越往里依赖越低，代码级别越高，越是核心能力。外圆代码依赖只能指向内圆，内圆不需要知道外圆的任何情况。
在洋葱架构中，各层的职能是这样划分的：
领域模型实现领域内核心业务逻辑，它封装了企业级的业务规则。领域模型的主体是实体，一个实体可以是一个带方法的对象，也可以是一个数据结构和方法集合。
领域服务实现涉及多个实体的复杂业务逻辑。
应用服务实现与用户操作相关的服务组合与编排，它包含了应用特有的业务流程规则，封装和实现了系统所有用例。
最外层主要提供适配的能力，适配能力分为主动适配和被动适配。主动适配主要实现外部用户、网页、批处理和自动化测试等对内层业务逻辑访问适配。被动适配主要是实现核心业务逻辑对基础资源访问的适配，比如数据库、缓存、文件系统和消息中间件等。
红圈内的领域模型、领域服务和应用服务一起组成软件核心业务能力。

六边形架构

六边形架构又名“端口适配器架构”。追溯微服务架构的渊源，一般都会涉及到六边形架构。
六边形架构的核心理念是：应用是通过端口与外部进行交互的。我想这也是微服务架构下 API 网关盛行的主要原因吧。
也就是说，在下图的六边形架构中，红圈内的核心业务逻辑（应用程序和领域模型）与外部资源（包括 APP、Web 应用以及数据库资源等）完全隔离，仅通过适配器进行交互。它解决了业务逻辑与用户界面的代码交错问题，很好地实现了前后端分离。六边形架构各层的依赖关系与整洁架构一样，都是由外向内依赖。
六边形架构将系统分为内六边形和外六边形两层，这两层的职能划分如下：
红圈内的六边形实现应用的核心业务逻辑；
外六边形完成外部应用、驱动和基础资源等的交互和访问，对前端应用以 API 主动适配的方式提供服务，对基础资源以依赖倒置被动适配的方式实现资源访问。
六边形架构的一个端口可能对应多个外部系统，不同的外部系统也可能会使用不同的适配器，由适配器负责协议转换。这就使得应用程序能够以一致的方式被用户、程序、自动化测试和批处理脚本使用。

三种微服务架构模型的对比和分析

虽然 DDD 分层架构、整洁架构、六边形架构的架构模型表现形式不一样，但你不要被它们的表象所迷惑，这三种架构模型的设计思想正是微服务架构高内聚低耦合原则的完美体现，而它们身上闪耀的正是以领域模型为中心的设计思想。
我们看下上面这张图，结合图示对这三种架构模型做一个分析。
请你重点关注图中的红色线框，它们是非常重要的分界线，这三种架构里面都有，它的作用就是将核心业务逻辑与外部应用、基础资源进行隔离。
红色框内部主要实现核心业务逻辑，但核心业务逻辑也是有差异的，有的业务逻辑属于领域模型的能力，有的则属于面向用户的用例和流程编排能力。按照这种功能的差异，我们在这三种架构中划分了应用层和领域层，来承担不同的业务逻辑。
领域层实现面向领域模型，实现领域模型的核心业务逻辑，属于原子模型，它需要保持领域模型和业务逻辑的稳定，对外提供稳定的细粒度的领域服务，所以它处于架构的核心位置。
应用层实现面向用户操作相关的用例和流程，对外提供粗粒度的 API 服务。它就像一个齿轮一样进行前台应用和领域层的适配，接收前台需求，随时做出响应和调整，尽量避免将前台需求传导到领域层。应用层作为配速齿轮则位于前台应用和领域层之间。
可以说，这三种架构都考虑了前端需求的变与领域模型的不变。需求变幻无穷，但变化总是有矩可循的，用户体验、操作习惯、市场环境以及管理流程的变化，往往会导致界面逻辑和流程的多变。但总体来说，不管前端如何变化，在企业没有大的变革的情况下，核心领域逻辑基本不会大变，所以领域模型相对稳定，而用例和流程则会随着外部应用需求而随时调整。把握好这个规律，我们就知道该如何设计应用层和领域层了。
架构模型通过分层的方式来控制需求变化从外到里对系统的影响，从外向里受需求影响逐步减小。面向用户的前端可以快速响应外部需求进行调整和发布，灵活多变，应用层通过服务组合和编排来实现业务流程的快速适配上线，减少传导到领域层的需求，使领域层保持长期稳定。
这样设计的好处很明显了，就是可以保证领域层的核心业务逻辑不会因为外部需求和流程的变动而调整，对于建立前台灵活、中台稳固的架构很有帮助。
看到这里，你是不是已经猜出中台和微服务设计的关键了呢？我给出的答案是：领域模型和微服务的合理分层设计。那么你的答案呢？

从三种架构模型看中台和微服务设计

结合这三种微服务架构模型的共性，下面我来谈谈中台和微服务设计的一些心得体会。
中台本质上是领域的子域，它可能是核心域，也可能是通用域或支撑域。通常大家认为阿里的中台对应 DDD 的通用域，将通用的公共能力沉淀为中台，对外提供通用共享服务。
中台作为子域还可以继续分解为子子域，在子域分解到合适大小，通过事件风暴划分限界上下文以后，就可以定义微服务了，微服务用来实现中台的能力。表面上看，DDD、中台、微服务这三者之间似乎没什么关联，实际上它们的关系是非常紧密的，组合在一起可以作为一个理论体系用于你的中台和微服务设计。

1. 中台建设要聚焦领域模型

中台需要站在全企业的高度考虑能力的共享和复用。
中台设计时，我们需要建立中台内所有限界上下文的领域模型，DDD 建模过程中会考虑架构演进和功能的重新组合。领域模型建立的过程会对业务和应用进行清晰的逻辑和物理边界（微服务）划分。领域模型的结果会影响到后续的系统模型、架构模型和代码模型，最终影响到微服务的拆分和项目落地。
因此，在中台设计中我们首先要聚焦领域模型，将它放在核心位置。

2. 微服务要有合理的架构分层

微服务设计要有分层的设计思想，让各层各司其职，建立松耦合的层间关系。
不要把与领域无关的逻辑放在领域层实现，保证领域层的纯洁和领域逻辑的稳定，避免污染领域模型。也不要把领域模型的业务逻辑放在应用层，这样会导致应用层过于庞大，最终领域模型会失焦。如果实在无法避免，我们可以引入防腐层，进行新老系统的适配和转换，过渡期完成后，可以直接将防腐层代码抛弃。
微服务内部的分层方式我们已经清楚了，那微服务之间是否也有层次依赖关系呢？如何实现微服务之间的服务集成？
有的微服务可以与前端应用集成，一起完成特定的业务，这是项目级微服务。而有的则是某个职责单一的中台微服务，企业级的业务流程需要将多个这样的微服务组合起来才能完成，这是企业级中台微服务。两类微服务由于复杂度不一样，集成方式也会有差异。
项目级微服务
项目级微服务的内部遵循分层架构模型就可以了。领域模型的核心逻辑在领域层实现，服务的组合和编排在应用层实现，通过 API 网关为前台应用提供服务，实现前后端分离。但项目级的微服务可能会调用其它微服务，你看在下面这张图中，比如某个项目级微服务 B 调用认证微服务 A，完成登录和权限认证。
通常项目级微服务之间的集成，发生在微服务的应用层，由应用服务调用其它微服务发布在 API 网关上的应用服务。你看下图中微服务 B 中红色框内的应用服务 B，它除了可以组合和编排自己的领域服务外，还可以组合和编排外部微服务的应用服务。它只要将编排后的服务发布到 API 网关供前端调用，这样前端就可以直接访问自己的微服务了。
企业级中台微服务
企业级的业务流程往往是多个中台微服务一起协作完成的，那跨中台的微服务如何实现集成呢？
企业级中台微服务的集成不能像项目级微服务一样，在某一个微服务内完成跨微服务的服务组合和编排。
我们可以在中台微服务之上增加一层，你看下面这张图，增加的这一层就位于红色框内，它的主要职能就是处理跨中台微服务的服务组合和编排，以及微服务之间的协调，它还可以完成前端不同渠道应用的适配。如果再将它的业务范围扩大一些，我可以将它做成一个面向不同行业和渠道的服务平台。
我们不妨借用 BFF（服务于前端的后端，Backend for Frontends）这个词，暂且称它为 BFF 微服务。BFF 微服务与其它微服务存在较大的差异，就是它没有领域模型，因此这个微服务内也不会有领域层。BFF 微服务可以承担应用层和用户接口层的主要职能，完成各个中台微服务的服务组合和编排，可以适配不同前端和渠道的要求。

3. 应用和资源的解耦与适配

传统以数据为中心的设计模式，应用会对数据库、缓存、文件系统等基础资源产生严重依赖。
正是由于它们之间的这种强依赖的关系，我们一旦更换基础资源就会对应用产生很大的影响，因此需要为应用和资源解耦。
在微服务架构中，应用层、领域层和基础层解耦是通过仓储模式，采用依赖倒置的设计方法来实现的。在应用设计中，我们会同步考虑和基础资源的代码适配，那么一旦基础设施资源出现变更（比如换数据库），就可以屏蔽资源变更对业务代码的影响，切断业务逻辑对基础资源的依赖，最终降低资源变更对应用的影响。

总结

今天我们详细讲解了整洁架构和六边形架构，并对包括 DDD 分层架构在内的三种微服务架构模进行对比分析，总结出了它们的共同特征，并从共性出发，梳理出了中台建模和微服务架构设计的几个要点，我们后面还会有更加详细的有关设计落地的讲述。
那从今天的内容中我们不难看出：DDD 分层架构、整洁架构、六边形架构都是以领域模型为核心，实行分层架构，内部核心业务逻辑与外部应用、资源隔离并解耦。请务必记好这个设计思想，今后会有大用处。

思考题

在系统设计时，你是如何避免外部需求对核心业务逻辑的影响的？有什么具体方法可以分享给大家吗？
欢迎留言分享，你也可以把今天所学分享给身边的朋友，邀请他一同交流、打卡。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 37

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
07 | DDD分层架构：有效降低层与层之间的依赖
下一篇
09 | 中台：数字转型后到底应该共享什么？
 写留言

精选留言(91)

  • ANYI
    2019-11-06
    微服务之间通过服务内部的应用层来连接多个微服务，微服务之间的相互调用；有两个疑问：1，微服务之间互相调用应该是什么样子？会不会就出现了网状微服务的调用关系结构了 2，是把这个夸多个微服务的应用层独立起来成为一个微服务（类似BFF微服务，没有领域）减少微服务之间调用关系？微服务之间就应该减少依赖调用？

    作者回复: 微服务之间要分两种情况，一种是项目级的少量微服务之间的调用。这样的调用可以放在微服务内的应用层，没必要再单独拿出一个微服务来进行服务组合和编排。 另外一种是复杂的企业级微服务调用和组合。拿出一个独立的BFF微服务的主要目的，一个是避免在一个微服务内组合太多的微服务的应用服务。二是，通过BFF微服务编排组合，可以减少由于前台的需求变化，传导到后端微服务中，可以降低后端微服务的发版频率，保持后端微服务的稳定。

    共 5 条评论
    38
  • lightSky
    2019-11-05
    关于这几种架构的区别，我觉得可以有一条原则作为主线，就是依赖倒置，不管是clean架构还是分层，或者六边形架构，都是高层次依赖于低层次的接口，都是为了实现关注点分离，提高代码的内聚性，隔离变化，最终达到稳定性的同时拥有良好的扩展性，架构最终都是趋同的，不同点就是他们在层与层之间的扩展点的方式不同。😄
    26
  • IT_matters
    2020-03-25
    您好，关于分层架构和六边形架构区别，在您给别人的评论中看到区别这样一段话。 ------------------------------ 主要区别还是在外围的适配上，端口适配器会给每个不同的场景，设计一个端口提供调用服务，这种是主动适配。还有一种是资源方面服务，是被动适配的方式。所有的外围对象都是平等的，可以是自动化的测试工具，也可以是APP。 DDD是通过接口层来对外提供服务接口，基础资源通过仓储依赖倒置使用资源，并实现解耦。 ------------------------------ 我感觉这二者还是一样的啊，如果分层架构在接口层，实现各种适配器，比如job，soa,rest。就可以说它是六边形架构了吗？有具体代码的例子吗，一望便知。从评论区来看，很多读者都对二者的区别比较疑惑。
    展开

    作者回复: 其实这三种架构是一种演化的关系。2003年DDD诞生，它是一种上下层的关系。六边形架构是在2005年提出，将这种上下层的关系演变为内外关系，内部代表了应用的业务逻辑，外部代表应用的驱动逻辑。但六边形架构的内层的业务逻辑还没有明显的领域模型的概念。2008年洋葱架构出现，六边形架构实际上是洋葱架构的一个超集。它与六边形架构有着相同的思路，都是通过编写适配器代码将应用逻辑从对基础设施的依赖中解放出来，避免基础设施代码渗透到应用逻辑中。洋葱架构在业务逻辑中加入了一些在领域驱动设计的分层的概念，比如用户接口层、应用层、领域层和基础层，另外它还明确了外层依赖内层，内层对外层无感知的这种依赖关系。虽然这三者之间在表达形式上存在差异，但它们的核心职责都是要做到核心业务逻辑和技术实现细节的分离和解耦。

    共 2 条评论
    19
  • steven
    2020-03-22
    应用层与领域层的区别，一般情况下还是很容易的。但是有些复杂的，也是经常会遇到的场景：比如某个A领域和B领域在C应用层作拼装时，会有业务判断的情况（比如需要综合判断A领域与B领域的对象，才能继续作后续的业务操作），此种情况下，如何设计才能避免这类问题呢？ 尽量避免跨领域的业务聚合是一种方法，但是很多情况下很难避免这类现象。
    展开

    作者回复: 这种情况是经常遇到的，所以在开发的时候，在应用服务对聚合与聚合之间的服务编排时不要采用对象依赖，采用ID的方式。因为如果未来聚合被拆分到不同的微服务的时候，原来在一个微服务内的对象依赖就不存在了，你需要调的代码量就会比较多。

    共 6 条评论
    13
  • 瓜瓜
    2019-10-30
    看完后，就是没区别。

    作者回复: 没有差异就不会有这么多叫法😄。它们几个其实是一点一点继承和发展过来的，在大的分层上基本上没什么太大的差异，思路基本是一致的，都是以领域模型为中心，加上用于编排的应用层逻辑。但是在分层的内部有一些小的差异。包括外部的适配方式也有差异。

    11
  • Geek_d94e60
    2019-11-13
    如果有了BFF这一层做统一编排，微服务内部还需要编排吗？如果碰到如下两种方案 A调用B， B再调用C A调用B , A再调用C 刚开始识别不出复用性，两个方案感觉都可行，如何抉择，有什么原则指导吗？

    作者回复: BFF做微服务之间的编排。微服务内的应用服务主要做领域服务的编排和聚合之间的协调。BFF是微服务之间的，应用服务是微服务内的。

    10
  • sundy
    2020-03-14
    始终不理解soa与中台有啥区别，感觉在技术上没什么创新

    作者回复: 中台体现的主要还是企业级的复用能力，它的价值不在技术上，可以说中台更偏业务。SOA或者微服务只是一种实现方式的不同。中台强调企业级内的整体解决方案。

    8
  • kevin
    2020-01-02
    有个点一直不太理解，还望老师解惑。 文章提到抽象出一个仓储的接口，与基础层的数据库进行解耦，方便后续有替换数据库。这种情况在实际场景中很少出现，选用合适的存储中间件是一件重要的事情，一般在项目初期就确定了，中途替换的概率很小，为了这样的小概率事件，是不是有些过度设计？

    作者回复: 现在技术发展这么快，一切皆有可能的。这样做其实也是将领域模型和资源逻辑解耦的过程。

    共 4 条评论
    6
  • TH
    2019-10-30
    想起了一句话：软件开发中遇到的所有问题，都可以通过增加一层抽象来解决。 对于依赖倒置的实现不是很清楚，按我的理解就是面向接口编程，由调用方将基础设施层的具体实现传入到被调用的服务，老师可以详细解释一下吗？

    作者回复: 是这样的。直白一点就是业务的归业务，基础的归基础，两者通过一层来适配，具体就是通过接口的方式。

    共 5 条评论
    6
  • Jxin
    2019-10-30
    回答问题： 1.为了支持外部应用，内部核心业务必须增加新逻辑。这种情况主要是要提高对价值的意识和风险的敏感。尽量不去加核心逻辑的代码，如果加了，必须是有足够价值的特性，且风险点可控或无。 2.为了支持外部应用，内部核心业务存在现有功能逻辑，但需调整兼容。这种情况就对该核心逻辑做进一步抽象，将通用部分复用，常变部分做抽象，实现更细力度的配置策略的定制能力。（当然也是要有足够价值）。 提问： 老的大项目并没有合理的架构分层。套到整洁架构上来看。 1.领域服务层会干领域模型的活。（贫血领域模型） 2.领域服务层会干应用层的活。（领域层大量rpc调用外部服务，并依托外部服务返回的dto做大量业务） 3.基础层会干领域服务的事。（dao层写业务，发mq，存solr，redis） 对于以上情况，做既有代码改善的小步重构，老师可有好套路或则思路？毕竟这种项目要大改规范，成本（时间）和风险（线上事故）都是接受不了的。（我重构了一遍，但是是业务架构上的。领域服务和基础层的职责越界并没有全量调整，仅是跟着需求，若涉及到就修修补补）
    展开

    作者回复: 这里你可以考虑单体架构的演进方式。可以先对系统做整体的领域建模分析，分解成多个不同的子域，建立领域模型。再根据优先级将部分领域模型对应的功能和数据从原来的单体应用中拆分出来，拆分为微服务。对原来的单体系统的前端提供API服务，原有系统的前端界面保持不变，整个架构演变用户无感知。当所有领域模型的微服务建设完成后，就可以抛弃原来的单体应用了。

    共 4 条评论
    6
  • y3
    2019-11-19
    请问老师，在设计微服务接口编排的时候，有哪些需要注意的地方？最好可以在github上给一个demo。

    作者回复: 你是说应用服务的编排吗？ 你把这种编排理解成在同一个微服务内，一个方法对多个不同方法的调用就可以了，如果涉及到外部微服务的接口调用，你需要做DO与DTO的数据转换。

    共 2 条评论
    4
  • 密码123456
    2019-10-30
    分层架构、整洁架构、六边形架构有什么区别？

    作者回复: 它们几个其实是一点一点继承和发展过来的，在大的分层上基本上没什么太大的差异，思路基本是一致的，都是以领域模型为中心，加上用于编排的应用层逻辑。但是在分层的内部有一些小的差异。包括外部的适配方式也有差异。

    共 3 条评论
    4
  • 默然
    2019-11-03
    领域服务被多个微服务依赖如何处理？ 举个例子，我们有中台微服务A、B、C，都是用同一个网关，之前渠道都是PC。现在加一个APP，展示ABC的数据，但是关注点不一样，PC更关注整体的情况，而APP更关注实时的数据。加了一个APP的中台D，现在在APP需要看B里的报表，同时还要在app中收藏、评论、分享。做数据的聚合太麻烦了，由于没有分库，我就直接在D里处理了。

    作者回复: 领域服务是不会暴露给多个微服务的。领域服务位于领域层，它只对应用层暴露。你说的领域服务是不是应用层的服务？ 你说的数据聚合的问题，不清楚你内部数据是如何分库分表的，是否是一个微服务一个库。 如果按照DDD的方法设计的话，应该是一个微服务一个库。微服务拆分后，数据肯定会更分散。有几种方案可以解决你这个问题。 第一种方式，如果数据量不大的话，可以采用冗余数据的方式，如果微服务B要用微服务A的数据的话，你可以将微服务A的部分数据冗余到微服务B中，它可能是实体也可能是值对象。 第二种方式，如果数据量比较大的话，可以建立一个集中的数据平台或者叫数据中台，这个平台会汇集各个微服务的数据，你可以建立数据模型，加工处理，以后涉及到多个微服务数据的查询就可以走这个平台。

    共 3 条评论
    3
  • Md3zed
    2021-01-28
    实体的职责是处理实体内的业务逻辑，领域服务的职责是处理实体外的业务逻辑，这两种都是在领域内的业务逻辑。应用层（服务）的职责就是粘合剂把领域内的原子能力进一步粘合封装对外提供粗粒度的领域能力。bff的职责就是充当微服务间（不同子域）的粘合剂作用，提供统一完整的业务逻辑。

    作者回复: 是的。

    共 2 条评论
    2
  • 开心小毛
    2020-05-08
    和使用注册中心相比，DDD落地中优先使用API网关么？ 使用API网关可用性会不会受影响，例如API网关自身的吞吐，以及需要额外的心跳检测确保服务提供在线。（如果使用zookeeper作为注册中心的话这些问题都可以避免）。那么API网关在DDD中如此流行的原因是什么呢，其比较优势在哪里。 谢谢老师解惑。

    作者回复: 微服务架构一般采用前后端分离设计，前端页面逻辑和后端微服务业务逻辑独立开发，独立部署，通过网关实现前后端集成。 前台应用接入中台微服务的技术组件一般是API网关。 API网关主要包括：鉴权、降级限流、流量分析、负载均衡、服务路由和访问日志等功能。API网关可以帮助用户，方便的管理微服务API接口，实现安全的前后端分离，实现高效的系统集成和精细的服务监控。

    共 3 条评论
    2
  • 莫离
    2020-03-26
    BFF就相当于没有自己单独的业务逻辑，只是把多个微服务拿来做流程编排，相当于故事串联的作用，是吧？那如果有微服务A的应用层需要依赖微服务B，怎么办呢？还有就是微服务A的领域服务内部的业务逻辑需要依赖另外一个微服务B，这种情况又怎么处理呢，把微服务B当作基础数据层来处理？

    作者回复: 是的，BFF主要是做组合和串联。 跨微服务或者聚合的服务调用，如果是项目级的应用你直接通过应用服务来组合和编排就可以了。如果领域服务依赖其他微服务的应用服务，你把这部分组合逻辑上移到应用服务就可以了。

    共 4 条评论
    2
  • 刘强
    2020-02-21
    看了这节课，我突然理解了我们公司的神人设计的思路了。他做了一个叫面向对象数据库的东西，暂且称为obd。我们开发的微服务不直接接触表，而是访问这个odb。有两个问题 1.他封装的这个odb就屏蔽了我们访问数据库的入口。 2.我们开发就没有了领域层，因为领域层都在odb里了，我们只需要开发应用层就好了，对吗

    作者回复: 你说的OBD应该只是做持久化吧。如果是这样，你一样还可以有领域层和应用层的。从OBD获取到持久化对象后，你就可以在领域层初始化领域对象，然后实现核心领域逻辑。

    共 4 条评论
    2
  • 金龟
    2019-12-29
    个人感觉项目级微服务这里有问题，服务a的应用层直接调用服务b的应用层，那如果服务b再调服务a应用层不就成环了。我觉得应该是应用层只能调取下层接口，服务a的应用层也只能调用服务b的领域层

    作者回复: 这种服务调用方式要尽量避免。在领域建模的时候，要根据服务地图和微服务的上下游关系把这种循环调用的方式切断。

    共 2 条评论
    3
  • Geek_88604f
    2019-12-15
    实际的项目中还存在一种集成方式：基于数据的集成。微服务A将外部的数据采集进来存储到对象存储服务上；微服务B批量处理这些数据，挖掘出数据关联规则存储到数仓中；微服务C从数仓中获取关联规则向用户呈现。微服务ABC之间并不存在直接的编排关系。

    作者回复: 是的，这种领域模型是一种贫领域模型。可能没有聚合根的概念。实体之间是独立的，服务与服务之间也没有分层和编排。

    2
  • 突围
    2022-01-29
    仓储模式，如何使用依赖倒置的设计方法来解耦，没太明白，能详细说下吗？ 这种模式，DAO层在各个业务微服务里吗？还是只是从代码层面隔离出来？
    1