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

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

开篇词 | 学好了DDD，你能做什么？-极客时间

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

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

讲述：欧创新

时长10:18大小9.40M

你好，我是欧创新，人保高级架构师，一名奋斗在软件架构一线十余年的技术人。
目前热衷于采用领域驱动设计（DDD）实现中台业务建模，专注基于 DDD 的微服务设计和开发等。另外，我也正在深入探索传统企业中台数字化转型的技术和方法体系。很高兴在这个专栏和你见面！

我与 DDD

说起 DDD 的实践，那就不得不提微服务了。2015 年，我刚开始接触微服务，那时候和别人去介绍微服务的设计理念，接受度并不高，毕竟大家普遍采用的还是集中式架构。
但即便是在四年前，业务的日渐复杂也是可以预见的，微服务的价值确确实实存在。我就从那个时候开始深入研究，作为公司的高级架构师，我也一直处于公司中台转型和微服务建设的一线。
这个过程中，我和我的技术团队踩过不少坑，最尖锐的一个问题是：“微服务到底怎么拆分和设计才算合理，拆多小才叫微服务？”而微服务的边界历来也是最容易产生争议的地方。
紧接着，阿里巴巴成功完成了中台战略转型。于是，很多大型公司也开启了中台数字化战略转型，中型公司也根据自身需求跃跃欲试。但也有很多公司由于历史原因，存在着大量系统重复建设的问题。
作为中台，需要将通用的可复用的业务能力沉淀到中台业务模型，实现企业级能力复用。因此中台面临的首要问题就是中台领域模型的重构。而中台落地时，依然会面临微服务设计和拆分的问题。这两个问题一前一后，放在任何一家公司，我想都是一个不小的挑战。
这也是我一直在探索和解决的问题。这两年，中台越来越火，微服务越来越热，参与的人越来越多。那是否有好的方法来指导中台和微服务的设计呢？
一次偶然的机会我接触到了 DDD，深入研究后，我发现，运用 DDD 设计思想实现的微服务边界确实清晰很多，业务领域划分也十分合理。后来，我和我的伙伴们用 DDD 做了很多的微服务实践。

关于专栏

有了这样一个基础，我开始尝试将我对 DDD 的理解和一些实践经验沉淀，并写了几篇文章发表在了 InfoQ 上。在读者的留言中，我发现很多人对 DDD 是有一定的了解的，但由于 DDD 的知识点多且较为抽象，体系庞大，又缺少实践经验和案例指导，很多人对 DDD 的应用都有这样那样的困惑，哪怕知道 DDD 的好处，但是也感到无从下手。
收到极客时间的邀请后，我就开始全力打造课程大纲，力求干货充盈，理论与实践并重。这做起来并不是一件轻松的事儿，专栏从确定主题到和你见面，已经耗时三个多月了。
DDD 虽然历史很久了，但它与微服务和中台设计的结合，却是一片很新的领域。早在 2003 年就诞生的 DDD，怎么来指导“迟到”近 20 年才大热的微服务设计呢？
我认为，要想应用 DDD，首要任务就是要吃透 DDD 的核心设计思想，搞清楚 DDD、微服务和中台之间的关系。中台本质是业务模型，微服务是业务模型的系统落地，DDD 是一种设计思想，它可以同时指导中台业务建模和微服务设计，它们之间就是这样的一个铁三角关系。DDD 强调领域模型和微服务设计的一体性，先有领域模型然后才有微服务，而不是脱离领域模型来谈微服务设计。
其次，就是通过战略设计，建立领域模型，划分微服务边界。这步是关键，你可以借助专栏中的一些经验。
最后，通过战术设计，我们会从领域模型转向微服务设计和落地。此时，边界清晰、可持续演进的微服务架构雏形就在你面前了。
遵循以上过程，这门课的设计思路也就诞生了。

关于课程设计

如果你以往对 DDD 的了解并不深入，甚至是第一次接触，你一定会觉得 DDD 的术语非常多，且非常陌生，这些术语之间的关系都算是个“拦路虎”。
搞懂这些之后呢，怎么应用它们，从何下手来设计领域模型等等这些问题又接踵而至。
如果你对 DDD 有过研究，在学会怎么用之后，你可能还会反过来想：“我费了这么大劲儿去搞懂它，那它到底会让我的系统变成什么样呢？可以解决什么具体问题？是不是真有大家说得那么好？”
这些都将是这个专栏要交付给你的内容。总结一下的话，我希望这个专栏能带给你这样几点收获：
用浅显易懂的案例带你了解 DDD 必知必会的 10 大核心概念，深入设计思想，厘清各知识域之间的关系；
用 DDD 分层架构带你弄懂微服务架构各层之间的关系，并完成微服务分层和代码模型设计；
用 DDD 战略设计和事件风暴带你完成领域建模和企业级中台业务建模；
用一个典型的案例带你完整走一遍 DDD 战略设计和战术设计的全流程，学习 DDD 在领域模型和微服务设计过程中的技术要点；
带你深化微服务架构设计原则和注意事项，建立适应你公司技术能力和文化的微服务，建立演进式的微服务架构。
希望这些收获能够给正在从事或者有兴趣深入了解微服务设计和中台的你，提供一些实质性的帮助。
在具体的课程设计上，我将内容分为了三大部分：基础篇、进阶篇和实战篇。下面我来逐一介绍一下。

基础篇

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

进阶篇

进阶篇主要讲解领域事件、DDD 分层架构、几种常见的微服务架构模型以及中台设计思想等内容。具体包括：
如何通过领域事件实现微服务解耦？
怎样进行微服务分层设计？
如何实现层与层之间的服务协作？
通过几种微服务架构模型的对比分析，让你了解领域模型和微服务分层的作用和价值。
另外，我还会介绍中台设计的核心思想，和你探讨如何实现前中后台的协同和融合？如何利用 DDD 进行中台设计？

实战篇

实战篇是我们专栏课程的重点，我准备了多个实战小项目。
中台和领域建模的实战：带你了解如何用 DDD 设计思想构建企业级可复用的中台业务模型，了解事件风暴以及用事件风暴构建领域模型的过程。
微服务设计实战：带你了解如何用 DDD 设计微服务代码模型，如何从领域模型完成微服务设计，建立领域模型与微服务代码模型的映射关系，如何完成微服务的架构演进等。
然后我会用一个典型的案例将 DDD 所有的知识点串联在一起，带你深入了解如何用 DDD 的设计思想来完成领域建模和微服务设计的全流程。
最后，我还会补充分享一个前端的最新设计思想，带你了解如何借鉴微服务的设计思想来设计前端应用，实现前端应用的解耦。同时，我还为你总结了微服务设计原则以及分布式架构设计的关键注意事项。
最后，我想说，DDD 看似复杂，可学习起来并不困难，多动手参与几次 DDD 事件风暴工作坊，你就能很快理解 DDD 的核心设计思想和设计过程，成功进阶了。
如果你的公司尚不能给你提供实战的机会，你可以在这里小试牛刀。
相信这个专栏会帮助你掌握一套完整而系统的基于 DDD 的微服务设计和拆分方法，明确从战略设计到战术设计的微服务标准设计过程，使得你的微服务设计思路能够更加清晰，设计过程更加规范，让你的中台和微服务落地如虎添翼。
最后，感谢你的关注。我也很想借此认识一下你，了解一下你对 DDD 都有哪些认知？是否有机会应用，学习过程中遇到过哪些困难？对这门课又有怎样的期待？欢迎你留言和我交流。
现在，就让我们一同开启 DDD 之旅吧！
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 116

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
下一篇
01 | 领域驱动设计：微服务设计为什么要选择DDD？
 写留言

精选留言(81)

  • errocks
    2019-10-27
    问一下, 这个专栏有学习群不

    编辑回复: 暂时没有，需要的小伙伴可以为errocks点赞，视人数而定。

    共 16 条评论
    526
  • Geek_88604f
    2019-11-15
    请问老师，中台和平台有什么区别与联系？

    作者回复: 平台只是将部分通用的公共能力独立为共享平台。虽然可以通过API或者数据对外提供公共共享服务，解决系统重复建设的问题，但这类平台并没有和企业内的其它平台或应用，实现页面、业务流程和数据从前端到后端的全面融合，并且没有将核心业务服务链路作为一个整体方案考虑，各平台仍然是分离且独立的。 中台来源于平台，但中台和平台相比，它更多体现的是一种理念的转变，它主要体现在这三个关键能力上：对前台业务的快速响应能力；企业级复用能力；从前台、中台到后台的设计、研发、页面操作、流程服务和数据的无缝联通、融合能力。 中台首先体现的是一种企业级的能力，它提供的是一套企业级的整体解决方案，解决小到企业、集团，大到生态圈的能力共享、联通和融合问题，支持业务和商业模式创新。通过平台联通和数据融合为用户提供一致的体验，更敏捷地支撑前台一线业务。

    共 5 条评论
    57
  • 吴建中
    2019-12-14
    关于区分平台与中台初步的认识，平台面向特定领域，偏技术，也有业务，避免重复建设，比如工作流引擎，移动平台，办公平台。平台之间是相对孤立的，在企业内会形成平台孤岛。而中台是企业级业务模型，面向的是业务，本质是业务，强调全局业务流，业务的互联互通，业务复用，相当于建立一个企业级的大系统，但不是单体应用，而是先从整体出发，再拆分成多个有内在关联的服务，由业务驱动各服务衔接。而技术上是通过微服务，分布式这种架构风格，来管理复杂度。微服务本来就复杂，需要成熟的平台，中间件，比如dubbou和springcloud，来降低复杂性。
    展开

    作者回复: 跟专栏的思路非常一致啊。

    共 4 条评论
    24
  • 南山
    2019-10-14
    前两天刚说再买剁手，今天看完开篇还是买了~工作中有过应用，也啃过砖头厚的实现领域驱动，还是有许多不明就里的细节以及应用上的困惑，希望跟着专栏，理解，应用都上一个台阶~
    共 1 条评论
    22
  • 流沙河
    2019-10-14
    个人的理解，中台的观察视角比较高一些，是给企业的高层人员的，是企业架构或者企业信息化整体战略的结果，阿里当时面临着天猫体系和淘宝体系以及聚划算等等多个相对独立的业务部门，各个业务部门的系统共享比较差，于是通过打造中台来将各个业务线的通用业务逻辑和通用系统抽取出来，逐步沉淀和优化，以至于后期各种新的业务应用可以快速的基于这套中台系统实现出来，形成了大中台小前台的状态，所以中台应该是一套通用业务系统的集合体。当然针对单个系统或者单个平台可以考虑微服务的系统架构设计，微服务系统的边界划分是个难题，DDD应该是个很好的设计思想。期待后续的课程。
    展开

    作者回复: DDD战略设计是用来建立业务模型的，适用于企业级的中台，同样也适用于项目级的领域建模。它的战术设计适用于微服务的设计，所以DDD是个好东西。希望能对你有所帮助。

    19
  • 天涯海峰
    2019-10-14
    实战课，开发语言用什么

    作者回复: DDD是一种架构设计方法，不限定语言，我习惯用JAVA，所以用JAVA做示例，你可以用你自己熟悉的语言来实战。

    16
  • Geek_778d19
    2019-10-31
    事件风暴工作坊？是指什么呢 ，如何参与进去？

    作者回复: 事件风暴类似头脑风暴，它是项目团队与领域专家聚集在一起，快速分析和分解复杂业务领域，完成领域建模的过程。 事件风暴是一项团队活动，项目团队通过头脑风暴的形式罗列出领域中所有的领域事件，整合之后形成最终的领域事件集合，然后对于每一个事件，标注出导致该事件的命令，再为每个事件标注出命令发起方的角色，命令可以是用户发起，也可以是第三方系统调用或者定时器触发等，最后对事件进行分类，整理出实体、聚合、聚合根以及限界上下文，建立领域模型。然后你就可以基于领域模型进行微服务设计了。

    共 3 条评论
    13
  • 特种流氓
    2019-10-29
    欧老师 可以讲讲 ddd与面向对象设计的区别及联系吗

    作者回复: DDD包括战略设计和战术设计，在战略设计时完成领域建模，战术设计实际上是落到了系统设计。它是根据领域模型中的领域对象以及他们的关系来完成设计，在这个设计过程中当然会有DDD战术设计自己的方法，比如聚合，实体，值对象，以及应用的内部分层架构，战术设计过程的大部分方法还是在用面向对象的设计方法。

    10
  • brant
    2020-04-08
    老师，请问一个问题。您觉得领域驱动的本质是啥，然后领域驱动的核心方法，实现策略是什么？

    作者回复: DDD和微服务其实都是从业务领域出发，将大的业务领域分解为小的子域，完成领域建模，用领域模型指导微服务设计和落地。两者都是采用分而治之的策略来降低业务领域认识和软件产品建设的复杂度。 领域驱动设计在领域建模的过程中最关键的就是完成了业务边界的划分，这个边界包括领域模型之间的边界，同时也包含了领域模型内部聚合之间的边界，有了这个边界就可以设计出高内聚低耦合的微服务。这是DDD战略设计阶段的关键内容。 而在DDD战术设计阶段，用DDD的分层架构实现微服务内各层之间解耦，很好的降低各层之间的依赖。在发生变化时，可以降低各层之间相互影响，保证各层模型的稳定。

    9
  • 雷霹雳的爸爸
    2019-10-30
    我算是刚入行时候案头就常备一本Eric Evans的 DDD（刚翻了一下是06年清华大学出版社的译本），别说真是少有的一本我从头到尾翻完了的书...但那时候看起来不啻为一本天书...只是我内心深处总是隐约觉得，终会有一天会在转角再次遇到他，果不其然，这本书在我桌上吃灰十年之后，随着微服务兴起，无论是理论领军人物Chris Richardson本尊，还是各路英豪，均又纷纷祭出DDD汲取养分，很难不让人重新对这本书，这些概念和方法重新产生兴趣，于是，为了表示尊敬，我在异步社区又入了一个电子书（应该是另一个译本），以数字化生存的方式让这本书继续在我这里吃灰，结果到现在自然还只剩下惭愧不已；这次，希望能跟随老师的专栏，把各路灰尘一扫而空，看看自己能否在此方向上有所真切的领悟，顺便瞄一瞄我这个做着运维管理工作但是深爱着DevOps工具的架构师最终的归宿到底是哪里...特么的本来是想来一篇檄文的，咋写着写着就这么伤感咧？
    展开

    作者回复: 😄，向执着于DDD的前辈致敬。

    共 3 条评论
    7
  • 葡萄吃葡萄皮
    2019-10-17
    现在对于DDD模型。持久化数据应该使用哪种比较合适？Mybatis?Spring Data JDBC? JPA?

    作者回复: DDD在基础层是通过仓储的控制反转的方式来实现应用与基础资源来解耦的。也就是说应用逻辑里面不应该含有基础资源的实现代码，SQL语句等与数据相关的代码不应放在业务逻辑代码来实现。以后如果需要换数据库的话，对应用逻辑影响相对会小很多。目前来说持久化的工具Mybatis可能会好一些。

    共 2 条评论
    6
  • G
    2019-10-16
    老师，有没有整理思维导图哈😊

    作者回复: 思维导图还没整理，可以先看下开篇词里的DDD知识体系图。等我后面有时间的时候再整理一下思维导图哈。

    6
  • 长空
    2020-01-14
    刚看到开篇词，我的一些问题也许在后面的学习中会解决，留言与作者交流下。我们组的问题： 1.水平要求高。据说DDD从设计到落地都需要人员的技术水平和理论水平比较高，有人跟不上容易导致最后出来的东西四不像。 2.历史包袱。我在的公司业务变化小，允许改进，但尽量求稳，比如数据库的表设计尽量不动，代码尽量不修改，一般一个改进周期都是3 4年。也就是向DDD演变需要尽量平缓
    展开

    作者回复: 1、要培养团队的DDD文化，因为DDD会从战略设计开始，建立领域模型后，作为微服务设计的输入，开始微服务的设计。而在微服务的开发过程中需要有相应的开发规范，以方便微服务内聚合之间的解耦，以便于未来的微服务的架构演进。很多的注意事项，我在专栏里有详细说明。 2、其实你们公司的系统可以按照微服务的绞杀者策略，逐步微服务化来实现演进，将部分开发质量不高或者存在性能问题的模块，先建立领域模型并独立为微服务，并对外提供服务，逐步实现遗留系统的微服务演进，这样就相对比较平缓了。

    5
  • 睁眼看世界
    2019-10-15
    一直感觉DDD概念太多，学习无从下手，更是无法应用于实战。老师这个系列真是及时！

    作者回复: 我刚接触也是这种感觉，其实熟悉起来也会很快的。做一两次领域建模和微服务设计就能理解透彻了。

    5
  • BennyTian
    2021-06-24
    请教一个问题: 我们的架构,目前有 adaptor: 适配层,主要负责 http/rpc的适配 app: 应用层,负责domain service的调用及编排 domain: 领域层,负责 实体/值对象/领域服务等核心业务编写 infra: 基础层,负责数据的存取等 app层 有一个 appService domain层 有一个 domainService 现在有一个下单业务场景,核心业务就是: 用户等级5级以上的才可以下单,否则拒绝 , 流程就两步: 1:校验用户等级是否满足 2:下单 该业务涉及到2个域,分别是 订单域 和 用户等级域, 当然, 用户等级也仅仅是最基础的查询,严格上说都算不上域. 现在的问题是: 用户等级校验这个操作, 原则上来说,和我的下单核心没有关系,仅仅是我下单的一个前置条件, 这个前置条件的判断,我是应该放在 appService去做呢? 还是放在domainService里去做呢? 如果放在appService里,则意味着我的业务分散到调用方了. 如果放在domainService里,那以后如果再加一个规则:管理员可以随意下单, 那我的domainService里是再次新增一个管理员下单的方法吗? 也就是说未来domainService里会有各种各样规则的下单接口.
    展开
    共 1 条评论
    4
  • 秋天
    2020-11-02
    学习ddd能够提高架构设计的能力吗？充实或者提升一下架构设计思路或者思想？谢谢

    作者回复: DDD是一套完整而系统的设计方法，它可以帮你建立一套从战略设计到战术设计的标准设计过程，让你的中台和微服务设计思路更加清晰，设计过程更加规范。DDD方法体系中有很多的设计思想、原则与模式，深刻理解后可以帮你提高微服务架构的设计能力。 在使用 DDD 进行微服务设计时，用到了很多解耦策略来实现领域模型和微服务设计的“高内聚，低耦合”。下面我们一起来总结一下，看看用到了哪些解耦策略？ 首先来看一下微服务或聚合之间的解耦策略。 ❏ 限界上下文实现了不同业务领域边界的微服务物理边界的解耦。 ❏ 聚合实现了微服务内不同聚合之间逻辑边界的解耦。 ❏ 微服务之间通过领域事件和消息中间件，以数据最终一致性的策略，实现了微服务之间的异步调用和服务解耦。 ❏ 通过适当的数据冗余设计，如值对象的业务快照数据设计，实现了跨微服务不同聚合之间的数据解耦。 再来看一下微服务内的解耦策略。 ❏ DDD 分层架构，通过分层和不同层的职责边界定义，实现了微服务内各层职能和代码的解耦。 ❏ 用户接口层通过 facade 接口和数据组装适配，实现了微服务核心业务逻辑与前端应用或用户解耦。 ❏ 仓储模式通过依赖倒置策略，实现了核心领域逻辑与基础资源处理逻辑的解耦。 ❏ 微服务代码目录通过聚合目录和分层目录代码边界，实现了不同职能代码边界的解 耦，有利于微服务架构演进时代码的组合和拆分。 ❏ 应用服务通过对不同聚合领域服务的组合和编排，实现了同一个微服务内不同聚合的解耦。 ❏ 聚合之间通过聚合根 ID 引用，而不是对象引用方式，完成不同聚合领域对象之间的访问，实现了聚合之间不同领域对象的解耦。 ❏ 微服务内聚合之间通过事件总线，采用数据最终一致性策略，实现了聚合之间服务同步调用的解耦。

    4
  • 又狗狗又丢丢
    2019-10-25
    请问不懂技术的产品经理适合参与课程吗

    作者回复: 非常适合的，DDD有战略设计和战术设计，战略设计主要偏战略和业务建模，并且战术设计时会将业务和技术很好的融合在一起。课程里会有中台业务建模的方法和案例介绍。

    4
  • 宇
    2019-10-21
    移动端可以学习吗

    作者回复: 如果移动端包含业务逻辑，可以建立领域模型是没有问题的。DDD是一种领域建模和微服务的设计方法。

    共 3 条评论
    4
  • zj
    2019-10-21
    问一下老师，一般增删改查有必要使用DDD模式开发吗，感觉增删改查用DDD代码写起来很麻烦

    作者回复: 要考虑系统的复杂度和成本，微服务虽然现在很流行，但有些场景下传统架构实现方式成本更低，效率更高。并不一定比传统架构有优势。所以这个需要结合你的业务和系统的情况来分析，如果可以构建领域模型，我建议你可以用DDD的设计方法，但是具体用不用它的战术设计，你需要结合你的团队情况，毕竟还是有一些复杂度的。

    共 2 条评论
    4
  • Eternal
    2020-11-04
    开启第二刷，然乎准备给部门做一次学习分享

    作者回复: 很好！我的书已经出版了。在京东搜索：中台架构与实现：基于DDD和微服务。

    3