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

01 | 领域驱动设计：微服务设计为什么要选择DDD？

01 | 领域驱动设计：微服务设计为什么要选择DDD？-极客时间

01 | 领域驱动设计：微服务设计为什么要选择DDD？

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

讲述：欧创新

时长14:41大小13.41M

你好，我是欧创新。
我们知道，微服务设计过程中往往会面临边界如何划定的问题，我经常看到项目团队为微服务到底应该拆多小而争得面红耳赤。不同的人会根据自己对微服务的理解而拆分出不同的微服务，于是大家各执一词，谁也说服不了谁，都觉得自己很有道理。
那在实际落地过程中，我也确实见过不少项目在面临这种微服务设计困惑时，是靠拍脑袋硬完成的，上线后运维的压力就可想而知了。那是否有合适的理论或设计方法来指导微服务设计呢？当你看到这一讲的题目时，我想你已经知道答案了。
没错，就是 DDD。那么今天我就给你详细讲解下：“微服务设计为什么要选择领域驱动设计？”

软件架构模式的演进

在进入今天的主题之前，我们先来了解下背景。
我们知道，这些年来随着设备和新技术的发展，软件的架构模式发生了很大的变化。软件架构模式大体来说经历了从单机、集中式到分布式微服务架构三个阶段的演进。随着分布式技术的快速兴起，我们已经进入到了微服务架构时代。
我们先来分析一下软件架构模式演进的三个阶段。
第一阶段是单机架构：采用面向过程的设计方法，系统包括客户端 UI 层和数据库两层，采用 C/S 架构模式，整个系统围绕数据库驱动设计和开发，并且总是从设计数据库和字段开始。
第二阶段是集中式架构：采用面向对象的设计方法，系统包括业务接入层、业务逻辑层和数据库层，采用经典的三层架构，也有部分应用采用传统的 SOA 架构。这种架构容易使系统变得臃肿，可扩展性和弹性伸缩性差。
第三阶段是分布式微服务架构：随着微服务架构理念的提出，集中式架构正向分布式微服务架构演进。微服务架构可以很好地实现应用之间的解耦，解决单体应用扩展性和弹性伸缩能力不足的问题。
我们知道，在单机和集中式架构时代，系统分析、设计和开发往往是独立、分阶段割裂进行的。
比如，在系统建设过程中，我们经常会看到这样的情形：A 负责提出需求，B 负责需求分析，C 负责系统设计，D 负责代码实现，这样的流程很长，经手的人也很多，很容易导致信息丢失。最后，就很容易导致需求、设计与代码实现的不一致，往往到了软件上线后，我们才发现很多功能并不是自己想要的，或者做出来的功能跟自己提出的需求偏差太大。
而且在单机和集中式架构这两种模式下，软件无法快速响应需求和业务的迅速变化，最终错失发展良机。此时，分布式微服务的出现就有点恰逢其时的意思了。

微服务设计和拆分的困境

那进入微服务架构时代以后，微服务确实也解决了原来采用集中式架构的单体应用的很多问题，比如扩展性、弹性伸缩能力、小规模团队的敏捷开发等等。
但在看到这些好处的同时，微服务实践过程中也产生了不少的争论和疑惑：微服务的粒度应该多大呀？微服务到底应该如何拆分和设计呢？微服务的边界应该在哪里？
可以说，很久以来都没有一套系统的理论和方法可以指导微服务的拆分，包括微服务架构模式的提出者 Martin Fowler 在提出微服务架构的时候，也没有告诉我们究竟应该如何拆分微服务。
于是，在这段较长的时间里，就有不少人对微服务的理解产生了一些曲解。有人认为：“微服务很简单，不过就是把原来一个单体包拆分为多个部署包，或者将原来的单体应用架构替换为一套支持微服务架构的技术框架，就算是微服务了。” 还有人说：“微服务嘛，就是要微要小，拆得越小效果越好。”
但我想，这两年，你在技术圈中一定听说过一些项目因为前期微服务拆分过度，导致项目复杂度过高，无法上线和运维。
综合来看，我认为微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方。换句话说，确定了业务边界和应用边界，这个困境也就迎刃而解了。
那如何确定，是否有相关理论或知识体系支持呢？在回答这些问题之前，我们先来了解一下领域驱动设计与微服务的前世今生。
2004 年埃里克·埃文斯（Eric Evans）发表了《领域驱动设计》（Domain-Driven Design –Tackling Complexity in the Heart of Software）这本书，从此领域驱动设计（Domain Driven Design，简称 DDD）诞生。DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。
但 DDD 提出后在软件开发领域一直都是“雷声大，雨点小”！直到 Martin Fowler 提出微服务架构，DDD 才真正迎来了自己的时代。
有些熟悉 DDD 设计方法的软件工程师在进行微服务设计时，发现可以利用 DDD 设计方法来建立领域模型，划分领域边界，再根据这些领域边界从业务视角来划分微服务边界。而按照 DDD 方法设计出的微服务的业务和应用边界都非常合理，可以很好地实现微服务内部和外部的“高内聚、低耦合”。于是越来越多的人开始把 DDD 作为微服务设计的指导思想。
现在，很多大型互联网企业已经将 DDD 设计方法作为微服务的主流设计方法了。DDD 也从过去“雷声大，雨点小”，开始真正火爆起来。

为什么 DDD 适合微服务？

“众里寻他千百度。蓦然回首，那人却在灯火阑珊处。”在经历了多年的迷茫和争论后，微服务终于寻到了他的心上人。
那 DDD 到底是何方神圣，拥有什么神器呢？
DDD 是一种处理高度复杂领域的设计思想，它试图分离技术实现的复杂性，并围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演进的问题。DDD 不是架构，而是一种架构设计方法论，它通过边界划分将复杂业务领域简单化，帮我们设计出清晰的领域和应用边界，可以很容易地实现架构演进。
DDD 包括战略设计和战术设计两部分。
战略设计主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。
战术设计则从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。
我们不妨来看看 DDD 是如何进行战略设计的。
DDD 战略设计会建立领域模型，领域模型可以用于指导微服务的设计和拆分。事件风暴是建立领域模型的主要方法，它是一个从发散到收敛的过程。它通常采用用例分析、场景分析和用户旅程分析，尽可能全面不遗漏地分解业务领域，并梳理领域对象之间的关系，这是一个发散的过程。事件风暴过程会产生很多的实体、命令、事件等领域对象，我们将这些领域对象从不同的维度进行聚类，形成如聚合、限界上下文等边界，建立领域模型，这就是一个收敛的过程。
我们可以用三步来划定领域模型和微服务的边界。
第一步：在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等，根据这些要素梳理出领域实体等领域对象。
第二步：根据领域实体之间的业务关联性，将业务紧密相关的实体进行组合形成聚合，同时确定聚合中的聚合根、值对象和实体。在这个图里，聚合之间的边界是第一层边界，它们在同一个微服务实例中运行，这个边界是逻辑边界，所以用虚线表示。
第三步：根据业务及语义边界等因素，将一个或者多个聚合划定在一个限界上下文内，形成领域模型。在这个图里，限界上下文之间的边界是第二层边界，这一层边界可能就是未来微服务的边界，不同限界上下文内的领域逻辑被隔离在不同的微服务实例中运行，物理上相互隔离，所以是物理边界，边界之间用实线来表示。
有了这两层边界，微服务的设计就不是什么难事了。
在战略设计中我们建立了领域模型，划定了业务领域的边界，建立了通用语言和限界上下文，确定了领域模型中各个领域对象的关系。到这儿，业务端领域模型的设计工作基本就完成了，这个过程同时也基本确定了应用端的微服务边界。
在从业务模型向微服务落地的过程中，也就是从战略设计向战术设计的实施过程中，我们会将领域模型中的领域对象与代码模型中的代码对象建立映射关系，将业务架构和系统架构进行绑定。当我们去响应业务变化调整业务架构和领域模型时，系统架构也会同时发生调整，并同步建立新的映射关系。

DDD 与微服务的关系

有了上面的讲解，现在我们不妨再次总结下 DDD 与微服务的关系。
DDD 是一种架构设计方法，微服务是一种架构风格，两者从本质上都是为了追求高响应力，而从业务视角去分离应用系统建设复杂度的手段。两者都强调从业务出发，其核心要义是强调根据业务发展，合理划分领域边界，持续调整现有架构，优化现有代码，以保持架构和代码的生命力，也就是我们常说的演进式架构。
DDD 主要关注：从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。
微服务主要关注：运行时的进程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署。

总结

今天我们主要讨论了微服务设计和拆分的难题。通过 DDD 战略设计可以建立领域模型，划定领域边界，解决微服务设计过程中，边界难以划定的难题。如果你的业务焦点在领域和领域逻辑，那么你就可以选择 DDD 作为微服务的设计方法！
更关键的一点是，DDD 不仅可以用于微服务设计，还可以很好地应用于企业中台的设计。如果你的企业正在做中台转型，DDD 将会是一把利器，它可以帮你建立一个非常好的企业级中台业务模型。有关这点你还会在后面的文章中见到详解。
除此之外，DDD 战术设计对设计和开发人员的要求相对较高，实现起来相对复杂。不同企业的研发管理能力和个人开发水平可能会存在差异。尤其对于传统企业而言，在战术设计落地的过程中，可能会存在一定挑战和困难，我建议你和你的公司如果有这方面的想法，就一定要谨慎评估自己的能力，选择最合适的方法落地 DDD。
也不妨根据收获权衡一下，总体来说，DDD 可以给你带来以下收获：
DDD 是一套完整而系统的设计方法，它能带给你从战略设计到战术设计的标准设计过程，使得你的设计思路能够更加清晰，设计过程更加规范。
DDD 善于处理与领域相关的拥有高复杂度业务的产品开发，通过它可以建立一个核心而稳定的领域模型，有利于领域知识的传递与传承。
DDD 强调团队与领域专家的合作，能够帮助你的团队建立一个沟通良好的氛围，构建一致的架构体系。
DDD 的设计思想、原则与模式有助于提高你的架构设计能力。
无论是在新项目中设计微服务，还是将系统从单体架构演进到微服务，都可以遵循 DDD 的架构原则。
DDD 不仅适用于微服务，也适用于传统的单体应用。

思考题

你的公司是否在实施微服务架构，你在微服务设计过程中面临的最大问题是什么？
欢迎留言和我分享你的思考和疑惑，你也可以把今天所学分享给身边的朋友，邀请他加入探讨，共同进步。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 82

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
开篇词 | 学好了DDD，你能做什么？
下一篇
02 | 领域、子域、核心域、通用域和支撑域：傻傻分不清？
 写留言

精选留言(133)

  • Geek_a91670
    置顶
    2019-10-21
    事件风暴到底是什么啊?

    作者回复: 后面章节会有一章专门讲，会有一个案例。跟头脑风暴类似，通过它设计领域模型。

    共 7 条评论
    12
  • 吴建中
    2019-12-14
    面对复杂问题，解决办法通常是拆分，模块化，化整为零。领域驱动建模DDD是面向业务，对业务领域的划分和整合，是逻辑层面。微服务是面向物理落地，是对应用的物理形态进行拆分和整合。从软件工程过程角度看，DDD的战略设计输出物，领域模型及划分的区域，是微服务的输入，一个区域对应一个微服务，微服务运行框架、平台可以承载所有的微服务，提供微服务统一的运行框架，也就是承载所有的业务领域。可见领域驱动与微服务是在软件不同阶段使用的工具，技术或方法论，围绕一个共同的目标，搭建企业业务中台，企业级业务复用，快速的需求响应能力。DDD战略设计得输出，是微服务的输入。
    展开

    作者回复: 👍高手，每节的总结可以交给你来做了😀。

    共 13 条评论
    191
  • SkyeDance
    2021-01-20
    翻了挺多留言，有一个感觉就是大家的容忍度特别低，总想把DDD的思想或者微服务架构一下子就在项目中完整的落地。就比如，只要使用DDD，在代码层面就不能使用MVC；只要使用微服务架构，就一定要基础设施完善，不然就是垃圾，这可能也是DDD一直推动不下去的原因之一。 人需要不断的学习，团队的认知也需要逐步的完善，是需要时间的。现在的代码是MVC的，没必要推翻，可以先在业务端多与市场、客户成功、产品等角色沟通，尝试用DDD的设计思想来建立合适的模型，等到团队都有这个sense的时候，再去慢慢搞定战术层面的东西。我认为，当业务领域模型足够健壮的时候，即使使用MVC模式，产品的健壮性和可维护性也会高很多。 只有让团队体会到领域设计的好处，才有可能继续推动DDD的落地。 另外一方面，微服务的基础设施也是逐步去构建完善，完全没有必要一开始就大而全。在业务初期，未必要建设庞大的监控系统，通过在代码中打印接口耗时、手动收集业务中的错误日志等方式来监控，也未尝不可，只要适合当前团队就好。 再者，也不用刻意去追求单元测试的覆盖率，能够保证重点业务接口的单元测试覆盖率即可。如果你真的有深入理解TDD的话，你就明白，TDD完全没有要求单元测试覆盖率这种指标，有些接口写单元测试真的只是浪费时间。 最后总结一下，饭是一口一口吃的，路也是一步一步走出来的，多给自己一点耐心，也多给团队一点时间。
    展开

    作者回复: 彩！

    共 9 条评论
    107
  • Geek_9695b4
    2019-10-25
    我们公司现在也有这方面的想法，但是一直无从下手，主要原因是， 1、我们是给工厂做软件的，不同的工厂相同的功能需求会有有差异，这个怎么解决？显然一个工厂一个版本是不好的 2、不同工厂需要使用不同的数据库 3、功能模块主要有物料管理、订单管理、计划管理、出入库管理、库存管理等，里面功能模块较多 4、DDD怎么更好的去解决SAAS化的产品研发问题
    展开

    作者回复: 第一个问题，我想知道不同工厂软件需求的差异主要在什么地方？如果差异在流程和服务编排，DDD的分层架构应用服务很合适。如果领域层业务逻辑差异不大的话，就比较好解决。个人感觉领域层的核心逻辑差异应该不会大。 第二个问题，DDD数据库方面采用依赖倒置的方式，实现业务逻辑的时候，不会有数据库方面的逻辑，都是领域对象的行为，数据库相关代码在仓储实现中实现。也就是说业务实现与数据库是松耦合的，换数据库的时候，只需要换仓储逻辑就可以了，不会影响核心业务逻辑。 第三方问题，你说的这几个子域相对清晰，直接在子域做事件风暴，建立领域模型，设计微服务就可以了。 第四个问题，见以上三条。总之，保持领域层领域模型的稳定，用应用层去适配外部需求的变化，用户接口层面向不同渠道提供个性数据服务。

    共 5 条评论
    47
  • 女干部
    2019-10-14
    我能说我等极客时间出这个等了1年吗？

    编辑回复: 忠实老粉了啊～期待你的打卡！

    共 8 条评论
    34
  • 雷霹雳的爸爸
    2019-10-30
    当然是微服务架构，不是也得跟投资人宣称是 要说最大的问题，就是业务拎不清；让我更进一步分析这种状况，应该是就没有事实上的领域专家，只有很多充其量是熟悉现有业务流程的人，而这些人站在自己的视角阐述问题都没有问题，但是缺少能捏合起来统筹考虑的人，在我们的组织中（我怀疑大多数组织中都是这样），在产品研发团队，关于业务的话语权特别是信息垄断权是掌握在产品（经理）部门手中的，而微服务、DDD的武器却是掌握在技术部门手中，如果技术人员不赶紧学好吃透这些招式，这就对微服务的实际落地，DDD的推广应用，带来了巨大的障碍和困难，我觉得也别无他法，只能忍着被误解和做好顶雷背锅的心态，像Carty说的那样，技术团队中有人挺身而出去承担本该产品经理的责任吧，这样才能给DDD，微服务落地准备足够的营养...我还记得在这个团队在成立初期，产品总监戏称应该定一个组织结构设计架构师的岗位，我估计他主要是说给我这个技术架构师听的，而我只能一脸严肃地表达，确实组织架构应该根据你系统演化的需要来变更的，我就差说你回去好好看看书去不行吗？
    展开

    作者回复: 其实你说的这种现象很普遍，很多企业都是业务的归业务，技术的归技术。不容易融合，这也是很多技术难以推行的原因。

    共 4 条评论
    27
  • 忠厚
    2020-03-22
    中台是战略目标，DDD是设计思想，微服务是落地手段，云原生是落地基础....企业数字化转型四大核心知识体系，一个都不能少，哈哈哈哈...

    作者回复: 是的，它们是整个中台体系的方法和技术框架。还缺少一个前端的设计：微前端。我在后面会讲到。

    共 3 条评论
    20
  • huaweichen
    2019-11-04
    我之前的公司从legacy单体应用转型为DDD微服务， 最大的问题是： 1. 使用消息队列的过程中，有很多事件不同步、死循环问题。 2. legacy数据库和新数据库的同步。 3. 做reporting的时候，不知道有什么好的招术。

    作者回复: 第一个问题，不清楚是设计的问题还是消息中间件组件选择的问题。 第二个问题，数据库之间的同步可以采用两种方式，第一种定时扫描源端数据库获取增量数据，但是这种方式会增加数据库的负担和需要单独编写取数代码逻辑。第二种是采用数据库日志捕获技术CDC，但是不知道你这种数据库是否有CDC，如果没有，就不太方便了。 第三个问题，不知道你的报表数据来源，如果是多个微服务，那建议你做一个数据平台，用于汇集各个微服务数据库的数据，所有的报表从这个数据平台获取。

    共 3 条评论
    18
  • 姚俊
    2019-10-15
    从2016年偶然间发现了springcloud springboot，于是开始带领团队玩起了微服务，在有一些技术积累之后，开始反过来看做过的项目，发现微服务的拆分并没有带来多少好好处，于是今年开始ddd试错。在拆分过程中，个人碰到的几大问题就是 1、数据库彻底拆分之后，带来的编码问题，和多服务调用的性能问题，举个例子，性别代码表，在n多个系统都需要的情况下，如果复制，也数据库没有彻底拆分，或者有冗余，彻底拆分的话，原来关联查询简单的sql，则变成服务之间的调用，可能存在性能问题。比较棘手 2、接触ddd有几个月吧，也在按照这个模式，重新构建项目，只是实体，聚合根在复杂的业务逻辑下，如何拆分和聚合，一直觉得没掌握到位。希望后续案例可以给我启发
    展开

    作者回复: 您说的第一个问题，尤其是数据代码类应用场景下都是存在的，这种情况下需要考虑必要的数据冗余，可以采用小表广播的方式，源端数据变了后，可以考虑异步方式广播到数据使用的目的端。 第二个拆分需要考虑限界上下文，并且保证业务的高内聚，高内聚你可以理解为原来的模块的概念，具体大小根据你的业务来定。

    13
  • 肖大保健
    2019-10-16
    目前公司用的是spring boot 框架，根据业务也做了明显得服务拆分（接单web，调度服务，订单服务，用户服务，资金服务，api服务 等），后期打算把数据层（mysql，mongo，redis）单独拆分出去，web层controller再单独拆分做HA 或者 ng，不知道算不算的上微服务架构，我们在做服务拆分，功能聚合这块是按业务模块来的 问题一：服务的功能界限该如何划定（按功能，还是按业务，有点矛盾） 问题二：服务调用，横向一个个调用，还是按web或者调度中转，比较好？（也存在争议） 问题三：文章中提到界定上下文，请问在服务中该如何体现，不是很明白
    展开

    作者回复: 你说的这几个问题我后面都会讲到，耐心等待哈。 第一个问题：会通过事件风暴来建立领域模型。 第二个问题：前后端分离后，可通过API网关调用后端微服务，或者对于复杂的业务场景可以考虑在前端与后端微服务之间增加一个BFF的微服务，可以对多个微服务进行服务组合和编排。 第三个问题：限界上下文边界理论上就是微服务的边界。

    12
  • Dr
    2019-10-14
    实战源代码，成体系吗？还是散落在文章里面？有的话，哪里可以下载？理论看了很多，缺一套代码，琢磨琢磨。

    作者回复: 选了一个企业级的中台设计，从领域建模到微服务设计选取了几个典型的中台，过程基本是完整的。最后的示例，源代码只到服务和实体类级别，里面具体业务实现代码没有。也就是说微服务整体架构的框架搭起来，但没有往里填肉。

    共 4 条评论
    10
  • 方堃
    2019-10-14
    我觉得微服务现在转型有个挺大的问题就是团队认识深度。因为现在好多项目都是先简单的以单机项目为基础开发，追求上线速度。后续发现项目越来越大才考虑进行架构方向的整理。导致很有可能出现早期只有开发产品没有架构师参与。这时候转型，架构师多久能吃透现有的业务就是转型速度的瓶颈了。毕竟产品不了解代码，开发人员又往往只盯着自己的模块缺少整体的了解

    作者回复: 您说的这些问题确实很常见，很多企业都是业务的归业务，技术的归技术。DDD其实也跟中台建设一样，也是一种企业和组织文化的变化，需要业务和技术融合在一起。

    10
  • Jxin
    2019-10-16
    1.一年前学的ddd，半年前学的重构，现如今项目从架构到核心业务都重构了。这个专栏，实在等了太久。 2.目前公司采用了微服务组件和框架。但绝对不是微服务，缺少合理的业务拆分，缺少对应的敏捷开发基建（没有cicd，没有测试用例，没有自动化回归测试，没有完善的监控平台，微服务技术的引入很可能弊大于利）。我将这架构认定为传统soa引入微服务组件和框架，依旧是传统soa。拆得再细都还是单体，因为每个服务不能自成体系，相互依赖严重。 3.难点很多。业务债高难还，员工（所有业务开发）在业务的架构抽象上认知太浅，基础架构平台从0搭建，效能工具平台从0搭建，最难的是，2b项目改造价值有限，如果没有升级为saas平台并带来额外利益的可能，那么一切改造都是空话，能用就行。
    展开

    作者回复: 微服务不只是微服务的事情。微服务的出现也不是偶然出现的，是技术和研发模式积累到一定阶段后才出现的。底层它与云计算平台、CICD、Devops等是离不开的，在研发模式上与敏捷也是关联非常紧密的。所以微服务的建设需要很多的积累，这些积累不够的话，对于企业级的微服务将会是很难的。

    9
  • TH
    2019-10-15
    DDD是针对业务的，那么到底怎么理解“业务”呢？什么属于业务，什么不属于业务呢？尤其是业务与技术、基础设施、中间件之间的关系怎么划分？ 换句话说，DDD是否适合技术框架、技术平台甚至技术中台的建设呢？比如我要开发一个代码部署系统或者配置管理系统，这样的系统是否适用DDD呢？因为对整个公司来说它们应该属于基础设施层的东西吧。 DDD是否存在大系统套小系统的形式？比如整个公司业务用DDD来设计，然后业务中的某个子系统也用DDD来设计，它们可以嵌套吗？
    展开

    作者回复: DDD包括战略设计和战术设计，战略设计主要面向业务完成领域建模，战术设计是根据领域模型完成微服务设计的过程。领域的概念应该包括您所说的代码部署系统或者配置管理系统，只要能在这些领域中能够提炼出领域模型就可以。

    共 5 条评论
    8
  • james.d
    2019-12-19
    微服务的关键不在服务的大小，在于边界是否清晰和有效隔离。单体应用向微服务架构演进的第一步是理清系统的领域架构，然后根据领域模型进行重构，每个领域都是“高内聚，低耦合”的模块，这样才能方便后期的拆分。至于服务拆分的大小，哪些需要拆，哪些不需要拆，哪些先拆，哪些后拆，还需要综合考量很多因素，比如团队的组织结构（小团队就不要拆分得太细了），性能，核心功能/非核心功能等等，业务拆分只是其中一小部分，数据拆分才是难点，总之先做好模块化（确定边界，做好隔离）才能实现想拆就拆。
    展开

    作者回复: 是的，单体向微服务架构演进过程中的数据拆分是难点。如果边界清晰就相对容易很多。

    7
  • Edward
    2019-11-12
    老师 如何能够用比较通俗的语言来解释soa与微服务的差别。尤其是针对企业IT部门的中高层，他们一般是懂一些计算机原理和编程技术，但是对什么是soa和微服务分不开，都以为是一个事情的不同阶段。

    作者回复: 其实也可以说微服务是SOA的延续和升华。但是他们中间的最大区别就是集中式和去中心化。传统的SOA通常是靠ESB之类的服务总线来管理服务，靠人肉来管理。而微服务架构下会有很多的配套的自动化的管理组件以保证能够去中心化，比如服务注册发现，熔断等等Spring Cloud的那些功能组件，这样的话可以更适合分布式的架构模式以及敏捷的开发模式，也更适合云环境下的部署。而SOA无法做到这些。微服务和SOA架构的对比，网上资料应该有很多。

    6
  • MaLu
    2019-10-21
    关于两层边界，聚合虚边界，限界物理实边界，很有启发，也给我一直困惑的，如果一个业务领域中，有多个聚合根的情形下，更加清晰与更好的理解。

    作者回复: 边界清晰了，以后微服务的演进就相对简单。一般来说聚合内部的功能都是核心的领域逻辑，是一些相对原子化的业务功能，受外部影响比较小。所以在微服务演进时可以以聚合为单元来进行微服务重组。

    6
  • 斯图尔特
    2019-10-15
    这里提到的业务人员是指？还有领域专家。套用公司场景，一个做企业服务，tob的公司，有自己的产品。这个过程中，有客户的需求，有项目经理的梳理客户需求。有产品经理对系统的规划，有客户成功提交的使用优化。这个过程中参与人，客户，项目经理，产品经理，客户成功。人员参与，那这些人在DDD领域模型的角色是？

    作者回复: 斯图尔特，你好。 领域模型里面都是一些领域对象，这些领域对象是构成系统的一些业务行为。你说的这些角色不知道是不是指系统建设过程中的角色。其实DDD并不改变原来软件开发过程中的角色，只是工作模式发生了变化，大家一起设计领域模型，设计微服务。领域专家是熟悉并深刻理解这个领域的人，可能是业务人员，也可能会是产品经理，甚至可能是开发人员。传统企业一般有信息和业务一说。业务人员一般是指业务部门的人员。

    6
  • KimZing
    2019-10-14
    没有DDD的微服务是没有灵魂的，新瓶装旧酒

    作者回复: 非常赞同！

    6
  • john_zhang
    2019-10-15
    toB的企业系统，用了微服务，但是还是采用传统的业务流程方式来开发的，感觉都是为了微服务而微服务，希望通过学习后能对DDD有一定的了解，并能对现有的系统进行优化。

    作者回复: 很多企业刚开始转型微服务的时候可能都有一个这样的过程。由于没有方法指导，还是在按照传统三层架构的模式做微服务，结果只是换了一套支持微服务的技术框架而已。DDD它是一个知识体系，就像一杯好茶，慢慢品，你就能品出其中的味道来。

    5