苏州能做网站沈阳seo搜索引擎

我的证书

课程

DDD 实战课

基于 DDD 的微服务拆分与设计

欧创新  人保资深架构师

已完结·共 26 讲 | 5.5w 人已学

你将获得

• DDD 必知必会 10 大核心概念
• 掌握事件风暴与领域建模
• 上手中台业务建模与设计
• 实战设计清晰的微服务架构

课程介绍

随着分布式技术的快速兴起，我们已经进入到了微服务架构时代。微服务架构的出现，很好地实现了应用之间的解耦，解决了单体应用扩展性和弹性伸缩能力不足的问题。随着业务的复杂度升级，其好处自然不言而喻。

那微服务到底怎么拆分和设计才算合理，拆多小才叫微服务？这个尖锐的问题，在业内一直被热议。紧接着，继阿里巴巴成功转型中台战略之后，微服务设计和拆分再至风口浪尖，对于众多公司来说，都是一个不小的挑战。

那有没有好的方法来指导微服务和中台的设计呢？当然有，你也可能耳闻过，那就是领域驱动设计（DDD）。

• 你可能会疑惑，早在 2003 年就诞生的 DDD，怎么来指导“迟到”近 20 年才大热的微服务设计？
• 怎么认识和学习这个抽象又庞大的知识体系？
• 怎么应用，怎么实践？
• 落地后它究竟能解决旧系统的哪些问题？

本专栏将重点解决以上问题，力求用浅显易懂的案例，深入 DDD 的核心知识体系与设计思想，带你掌握一套完整而系统的基于 DDD 的微服务拆分与设计方法，明确从战略设计到战术设计的微服务标准设计过程，助力落地边界清晰、可持续演进的微服务架构。

具体内容上，专栏共 21 讲，分为基础篇、进阶篇和实战篇三部分。

基础篇主要讲解 DDD 的核心知识体系，具体包括：领域、子域、限界上下文、实体、值对象、聚合和聚合根等概念。借助浅显易懂的案例，带你理解它们以及它们之间的合作、依赖关系。

进阶篇主要讲解领域事件、DDD 分层架构、几种常见的微服务架构模型以及中台设计思想等内容。带你深入微服务分层设计的底层原理与具体实现。

实战篇作为本课程的重点，包含多个实战小项目，例如中台和领域建模的实战、微服务设计实战等。最后作者会用一个典型的案例将 DDD 所有的知识点串联，带你走一遍基于 DDD 的微服务设计全流程。

另外，实战篇还补充有“如何借鉴微服务的设计思想来设计前端应用”“微服务设计原则”以及“分布式架构设计的关键注意事项”，以完善实战体系。

讲师

欧创新

人保资深架构师

欧创新，人保资深架构师，《中台架构与实现：基于 DDD 和微服务》作者，拥有十多年的软件架构经验。他热衷于采用 DDD 的设计方法实现中台业务建模，专注基于 DDD 的微服务设计和开发。目前，他正在深入探索传统企业中台数字化转型的技术和方法体系。

课程目录

开篇词 (1讲)

开篇词 | 学好了DDD，你能做什么？

时长 10:18

基础篇 (5讲)

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

时长 14:41

02 | 领域、子域、核心域、通用域和支撑域：傻傻分不清？

时长 13:06

03 | 限界上下文：定义领域边界的利器

时长 14:18

04 | 实体和值对象：从领域模型的基础单元看系统设计

时长 18:56

05 | 聚合和聚合根：怎样设计聚合？

时长 13:21

进阶篇 (6讲)

06 | 领域事件：解耦微服务的关键

时长 17:38

07 | DDD分层架构：有效降低层与层之间的依赖

时长 16:45

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

时长 16:34

09 | 中台：数字转型后到底应该共享什么？

时长 18:23

10 | DDD、中台和微服务：它们是如何协作的？

时长 14:32

答疑：有关3个典型问题的讲解

时长 11:03

实战篇 (10讲)

11 | DDD实践：如何用DDD重构中台业务模型？

时长 19:26

12 | 领域建模：如何用事件风暴构建领域模型？

时长 16:06

13 | 代码模型（上）：如何使用DDD设计微服务代码模型？

时长 15:15

14 | 代码模型（下）：如何保证领域模型与代码模型的一致性？

时长 19:03

15 | 边界：微服务的各种边界在架构演进中的作用？

时长 11:30

16 | 视图：如何实现服务和数据在微服务各层的协作？

时长 17:24

17 | 从后端到前端：微服务后，前端如何设计？

时长 21:11

18 | 知识点串讲：基于DDD的微服务设计实例

时长 21:20

19 | 总结（一）：微服务设计和拆分要坚持哪些原则？

时长 18:19

20 | 总结（二）：分布式架构关键设计10问

时长 19:10

结束语 (1讲)

结束语 | 所谓高手，就是跨过坑和大海！

时长 08:18

专栏加餐 (2讲)

基于DDD的微服务设计实例代码详解

时长 26:01

抽奖｜《DDD实战课》沉淀成书了，感谢有你！

时长 09:26

期末测试 (1讲)

期末测试 | 有关DDD的内容，你掌握了多少呢？

时长 00:30

精彩内容

“跨多个实体的业务逻辑通过领域服务来实现，跨多个聚合的业务逻辑通过应用服务来实现”

来自：05 | 聚合和聚合根：怎样设计聚合？

38 人划过

“领域建模时，我们可以将部分对象设计为值对象，保留对象的业务涵义，同时又减少了实体的数量；在数据建模时，我们可以将值对象嵌入实体，减少实体表的数量，简化数据库设计”

来自：04 | 实体和值对象：从领域模型的基础单元看系统设计

22 人划过

“理论上限界上下文就是微服务的边界。我们将限界上下文内的领域模型映射到微服务，就完成了从问题域到软件的解决方案”

来自：03 | 限界上下文：定义领域边界的利器

15 人划过

“需求变幻无穷，但变化总是有矩可循”

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

9 人划过

“为了实现微服务内聚合之间的解耦，聚合之间的服务调用和数据交互应通过应用服务来完成。原则上我们应该禁止聚合之间的领域服务直接调用和聚合之间的数据表关联。”

来自：16 | 视图：如何实现服务和数据在微服务各层的协作？

8 人划过

“事件风暴是一项团队活动，领域专家与项目团队通过头脑风暴的形式，罗列出领域中所有的领域事件，整合之后形成最终的领域事件集合，然后对每一个事件，标注出导致该事件的命令，再为每一个事件标注出命令发起方的角色。命令可以是用户发起，也可以是第三方系统调用或者定时器触发等，最后对事件进行分类，整理出实体、聚合、聚合根以及限界上下文。而事件风暴正是 DDD 战略设计中经常使用的一种方法，它可以快速分析和分解复杂的业务领域，完成领域建模”

来自：12 | 领域建模：如何用事件风暴构建领域模型？

8 人划过

“中台来源于平台，但中台和平台相比，它更多体现的是一种理念的转变，它主要体现在这三个关键能力上：对前台业务的快速响应能力；企业级复用能力；从前台、中台到后台的设计、研发、页面操作、流程服务和数据的无缝联通、融合能力。”

来自：09 | 中台：数字转型后到底应该共享什么？

5 人划过

“从目前来看，还没有可以量化的领域以及限界上下文的划分标准。它主要依赖领域专家经验，以及和项目团队在事件风暴过程中不断地权衡和分析。不要奢望一次迭代就能够给复杂的业务，建立一个完美的领域模型。领域模型很多时候也需要多次迭代才能成型，它也需要不断地演进”

来自：答疑：有关3个典型问题的讲解

5 人划过

“随着业务的发展或需求的变更，在不断重新拆分或者组合成新的微服务的过程中，不会大幅增加软件开发和维护的成本，并且这个架构演进的过程是非常轻松、简单的”

来自：15 | 边界：微服务的各种边界在架构演进中的作用？

5 人划过

“所以如果有的实体方法需要被前端应用调用，我们会将它封装成领域服务，然后再封装为应用服务”

来自：14 | 代码模型（下）：如何保证领域模型与代码模型的一致性？

5 人划过

*精彩内容为该课程各文章中划线次数最多的内容

课程评价

南山

从专栏出来一篇没有落下的跟到现在，时间真的好快！ 收获良多，算是入了ddd的门，重术(战术)更要重道(战略)，后续打算把ddd分享给身边的人，至少一起码的人要有所了解，有相同的语言，才能一起聊下去 感谢老师，江湖再见！！！

作者回复：江湖再见！

2019-12-02

keep moving

同是保险行业，学完本课程收货很大，之前看了写书理论偏多，本课程中老师分享了很多实践经验，以及具体实施步骤，受益匪浅，感谢。

2022-06-26

1

祥敏

欧老师的课程内容富有层次，注重整体。 不能一下子都吸收，后序要反复实践、归纳整理，如此循环才能跨过坑和大海。

作者回复：谢谢，建议来回多看几遍。

2019-12-04

1

墨名次

第一次学习这种几乎纯理论的课程确实很考验耐心，幸运的是老师这种讲课方式很适合我，全部学习了，收获很大，感谢！

作者回复：谢谢你的耐心陪伴。

2019-12-02

2

风

老师的专栏组织的很好，既有基础知识的普及，也有原理的分析，还有落地的实战。感谢老师用心的总结与分享，虽然我看到这还有很多云里雾里，这是因为干货太多，自己的脑子不够用而已，计划再看几遍，每篇文章的留言也过一遍

作者回复：很好，建议多看几遍，慢慢思考和品。我的书《中台架构与实现：基于DDD和微服务》也出版了，大家在专栏中提出的有些问题，在书里面也会有集中解答。

2020-11-10



常文龙

看了很多同道中人提了类似的疑问，分享一下自己的灵魂问题的回答： Q1.一个逻辑，貌似放在应用层、领域服务层、甚至聚合根本身都可以，到底什么是准绳？ A1. （1）首先，分层的本质是为了复用和内聚，切不可成为作茧自缚的存在。 （2）其次，其实每层的定位，老师也说了，应用层是做跨聚合操作的，领域服务层是做聚合内的跨实体操作，而聚合根是自身能触达的对象的。 其实后两者有点含糊，因为聚合根理论上是聚合内四通八达的对象，但领域服务也是。从大家的共识看来，大家都更喜欢纯getter/setter的“容器模型”，而不是一个有“行为”的对象。这点其实老师在案例和回复也默认了，觉得很简单的才放进聚合根（案例里聚合根也就组合了几个setter，搞搞当前时间而已）。 （3）那么，假如觉得放在哪都行，说明他很可能根本就是一个聚合根的“DB基操”，譬如查询、更新请假单这两个操作，压根就是查库、写库。这时候自然是越底层越好（因为越底层将来就越有复用的可能），因此就放在领域服务层了。 Q2：文中一直提到，一旦拆分，引用会失效。 A2： （1）可能是因为我一开始就接触了dubbo之类的rpc框架，我没觉得有什么失效的，毕竟对于dubbo而言，不用考虑是否走网络，将来拆分，大不了为领域对象做个jar包就完事了。 （2）但按照老师说的，的确有一个好处，就是面向抽象，对于调用方来说，不用new大对象了，也不用担心自己set少了东西会导致问题。说白了，就是把关键的信息传过来得了。 Q3:仓储到底解决了什么问题？比起DAO有什么区别？ A3: （1）首先，从老师的案例看来，仓储是依赖了DAO的。而且可以看出，仓储最大的特点，是一个add方法背后偷偷处理了N个表，而不是一个纯纯的小表。 （2）那么更深的灵魂问题来了，从仓储的定位是抽象存储，为何DO转PO这件事会发生在领域服务层（案例里，领域服务调用的factory方法）？按我的理解，至少仓储应该接受、返回DO才对。这点我目前不能理解，还是希望得到老师的回答。 （3）其实大部分互联网公司，尤其java栈都不存在换数据库的担忧，至少SQL大部分时候是标准的、JDBC也是抽象了数据库驱动的。因此，DAO这种读写库的模式已经很够用了。 Q4：DDD到底给我什么意义，解决了目前什么困境？ A4：目前来看，DDD有两个深刻的意义，是我过去没领会到的。 （1）提醒了我，世界上有 领域驱动 vs. 数据驱动 两种套路（不说我都没意识到，这自上而下，自下而上的结果可能大不相同） （2）给了我一个划分“领域、聚合”两种范围，“实体（聚合根）、值对象、事件、命令”这个世界观，以及对应的需求分析方法论。 Q5:值对象的价值在哪？ A5: （1）值对象本是Martin发现基于引用的编程语言在相等比较、写操作的时候互相干扰的问题而特地发明的概念，要求大家不能在值对象做局部写，而只能整个替换。然而实际上大家往往会通过克隆对象避免误写，通过简单的重写equal解决比较，犯不着新增概念。 （2）但我觉的值对象目前有一个更实在好处，就是当两个割裂的模型发生关联的时候，可以作为“快照”或者“实例”的表达。譬如案例中的人员在请假聚合里，表现为“请假人”、“审批者”，这时候只留下人员的名称和id，其他不留。这也意味着，这个人员改名了，在请假单里也是旧的名字（希望这是真实需求吧）。

2021-07-11

26

dongdong5820

总结：事件风暴中，我们会根据一些业务操作和行为找出实体(Entity)和值对象(ValueObject)，进而将业务关联紧密的实体和值对象进行组合，构成聚合。再根据业务语义将多个聚合划定到同一个限界上下文(Bounded Context)中，并在限界上下文内完成领域建模。

2021-01-21



SkyeDance

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

作者回复：彩！

2021-01-20

126

keys头

欧老师，共享的数据类微服务，也就是数据代码类的数据字典系统应该怎么设计？有什么要点和注意事项吗？某一类字典数据可能只有一张表，是不是有必要把其他类的数据也放到同一个微服务中？比方说品牌库和行业库，各自都只有增删改查的功能。另外，有没有什么好的资料可以提供参考？

作者回复：这类业务没有太多的业务逻辑，所以基本没有领域模型的概念，整个业务逻辑读多写少，其微服务主要是提供查询服务，所以按照传统方式设计也是可以的，不必先构建领域模型，然后设计微服务。 但是这类数据可能会与业务数据进行组合查询的可能，而他们分别在不同的微服务中。这时，你可以将这部分代码类数据以事件驱动的方式复制到业务数据库中。另外如果业务系统需要考虑多中心多活，这部分数据可能需要部署在不同的数据中心，这类数据属于全局数据，这时可以按照一写多读的设计方式，在一个地集中完成写入，而在多个数据中心提供读的数据副本，为多个数据中心提供数据查询服务。

2021-01-19​​​​​​​