DDD实战课
欧创新
人保高级架构师
立即订阅
4865 人已学习
课程目录
已完结 23 讲
0/2登录后,你可以任选2讲全文学习。
开篇词 (1讲)
开篇词 | 学好了DDD,你能做什么?
免费
基础篇 (5讲)
01 | 领域驱动设计:微服务设计为什么要选择DDD?
02 | 领域、子域、核心域、通用域和支撑域:傻傻分不清?
03 | 限界上下文:定义领域边界的利器
04 | 实体和值对象:从领域模型的基础单元看系统设计
05 | 聚合和聚合根:怎样设计聚合?
进阶篇 (6讲)
06 | 领域事件:解耦微服务的关键
07 | DDD分层架构:有效降低层与层之间的依赖
08 | 微服务架构模型:几种常见模型的对比和分析
09 | 中台:数字转型后到底应该共享什么?
10 | DDD、中台和微服务:它们是如何协作的?
答疑:有关3个典型问题的讲解
实战篇 (10讲)
11 | DDD实践:如何用DDD重构中台业务模型?
12 | 领域建模:如何用事件风暴构建领域模型?
13 | 代码模型(上):如何使用DDD设计微服务代码模型?
14 | 代码模型(下):如何保证领域模型与代码模型的一致性?
15 | 边界:微服务的各种边界在架构演进中的作用?
16 | 视图:如何实现服务和数据在微服务各层的协作?
17 | 从后端到前端:微服务后,前端如何设计?
18 | 知识点串讲:基于DDD的微服务设计实例
19 | 总结(一):微服务设计和拆分要坚持哪些原则?
20 | 总结(二):分布式架构关键设计10问
结束语 (1讲)
结束语 | 所谓高手,就是跨过坑和大海!
DDD实战课
登录|注册

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

欧创新 2019-11-08
你好,我是欧创新。
进入两千年后,随着互联网应用的快速发展,很多传统企业开始触网,建设自己的互联网电商平台。后来又随着微信和 App 等移动互联应用的兴起,又形成了新一轮的移动应用热潮。这些移动互联应用大多面向个人或者第三方,市场和需求变化快,需要以更敏捷的速度适应市场变化,为了保持快速响应能力和频繁发版的要求,很多时候这些移动互联网应用是独立于传统核心系统建设的,但两者承载的业务大部分又都是同质的,因此很容易出现业务能力重叠的问题。
阿里巴巴过去带动了传统企业向互联网电商转型。而如今又到了一个新的历史时期,在阿里巴巴提出中台战略后,很多企业又紧跟它的步伐,高举中台大旗,轰轰烈烈地开始了数字化转型之路。
那么传统企业在中台转型时,该如何从错综复杂的业务中构建中台业务模型呢?今天我就用一个传统企业中台建模的案例,带你一起用 DDD 的设计思想来构建中台业务模型。

传统企业应用分析

互联网电商平台和传统核心应用,两者面向的渠道和客户不一样,但销售的产品却很相似,它们之间的业务模型既有相同的地方,又有不同的地方。
现在我拿保险行业的互联网电商和传统核心应用来做个对比分析。我们看一下下面这张图,这两者在业务功能上会有很多相似和差异,这种相似和差异主要体现在四个方面。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DDD实战课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(21)

  • 深山小书童
    接触ddd的概念也蛮多年了,确实如老师所说,微服务的兴起让大家有自然的想起了ddd。但是要将ddd落地,不知道在代码层面如何去分层是最让人困扰的。以java web开发为例,controller,dao,service怎么和应用服务,领域服务,聚合等对应起来呢?老师能不能展示一下框架里面怎么去组织这些概念,这样作为研发人员会比较好理解。ddd的经典三本书里面就是缺少这种东西,互联网小厂由于能力有限很难将其理解和落地。一直期待一门课从代码层面开始自底向上来讲解ddd,反而会更好理解。一直反复讲ddd的好处,感觉浮在表面。

    作者回复: 其实DDD的核心思想是在于划分领域边界从而来解耦。我认为领域模型才是DDD在微服务设计的关键,只有构建了边界清晰的领域模型的边界,才有可能设计出高质量的微服务。在建立领域模型后,微服务内部可以用DDD战术设计方法,传统的开发方法也不是不可以,有时候在性能方面表现更优秀。
    后面我有一节专门讲解这些对象之间是如何协作的,另外也有一讲来介绍DDD的代码目录结构和模型。

    2019-11-08
    2
    4
  • 墨名次
    DDD是中台、微服务的产品经理

    作者回复: 比喻很形象!

    2019-11-09
    1
    3
  • 祥敏
    看来要公布Github的仓库了,要不怎么是实践篇@@@

    作者回复: DDD用于微服务设计的关键就是先建立领域模型,有了边界清晰的领域模型,才能设计出高质量的微服务。在微服务设计时不能脱离领域模型来谈微服务。它们两者之间是必不可少的前后贯通的关系,可能开发人员只关心用DDD来做微服务的开发,并不关心领域建模。领域建模就是DDD的战略实战。而且这种战略设计和分析过程比战术设计更重要。

    2019-11-08
    1
    2
  • 小毅
    建议老师,多讲讲怎么做的领域、聚合根、实体的划分,讲讲实施层面怎么做的?而不是直接抛出你最终的结果,我觉得这才是要学DDD的精髓。看到现在知道了很多名词,但是依然并不知道DDD具体如何实施,具体场景下拿什么依据作为划分和聚类的参考~

    建议对于文章中的例子,比如您举的保险类例子,可以多补充些业务背景,这样才能在战术层面搞明白实施和落地的流程,而不是悬浮在半空中~

    作者回复: 这一节信息量比较大,后面小的案例里有介绍。

    2019-11-08
    2
  • 瓜瓜
    聚合内的实体都是通过聚合根来进行访问的,这个有没有相关的例子,感谢老师

    作者回复: 聚合根内会定义引用的实体,在聚合根内部直接使用引用的实体属性或者方法就可以了。
    这些实体的方法会被封装成领域服务或者应用服务。外界不需要关心这些实体内的属性或者方法实现了。

    2019-11-24
    1
  • 蜗牛慢慢爬
    看了11个课程了,最大的疑问就是怎么划分? 老师每次都拿出你已经划分好的领域,感觉很空泛,领会不到精髓

    作者回复: 这一节的内容有点多,没有做过细的分析,你可以看下一节哈。第12节有详细的领域建模分析过程。

    2019-11-11
    1
  • Scott
    很多人提到代码,其实代码方面我觉得可以看看 Domain modeling made functional 这书。
    2019-11-09
    1
  • 沉迷于学习无法自拔
    看到这一章,我突然有一个新的想法,但不知道对不对。中台和中间件类似,但不同的是,中间件是解决技术层面上的问题,中台是解决业务层面上的问题。比如说,中间件kafka用来提供异步、解耦、削峰功能;中台用户用来提供用户、权限、认证功能

    作者回复: 从复用的角度来看,目标是一致的,都是将公共的能力沉淀,然后复用。

    2019-11-25
  • Geek_4de168
    老师,可不可以用代码示例一下,每集都听了几回,但还是不理解

    作者回复: 前面主要是基础知识,后面会有一些代码方面的示例。到服务和方法级。

    2019-11-15
  • ff
    转型的话,感觉自顶向下和自底向上都需要
    自顶向下确定的是目标,但是整个推倒重来一般都是不现实的(而且大部分情况下还需要保证服务稳定和对用户不可见),只能逐步演进
    自底向上是认清现实,找到一条通向目标的路

    作者回复: 是的,要根据企业情况具体分析。

    2019-11-15
  • 川杰
    对核心中台和通用中台有点疑惑,说下自己的理解:核心中台就是和业务强相关的,通用中台就是,即使不是保险业务,换成金融业务,也可以用;
    请问是这个意思吗?

    作者回复: 是的。通用的话,企业内能被很多地方复用也算。

    2019-11-14
  • yopai
    欧老师好,我说下我对ddd在中台建设中所起作用的看法,不当之处请指点;ddd为中台所涉及到的领域模型梳理提供了方法指引,并对微服务的划分提供了参考标准;但有了这些对一个业务中台的建设还不是完备的;因为中台提供了业务能力服用层,也就是说抽象出了可服用的公共能力,但每个使用该能力的场景是不一样的,这样在该能力上的定制需求的满足是就出现了,这就需要中台有扩展能力,来适应这些需求;所以中台建设不单是微服务的合理拆分,可扩展能力的架构设计也是中台建设的关键;

    作者回复: 是这样的。

    2019-11-13
  • 瓜瓜
    划分清楚业务域,是战略设计中的核心,因为只有划分清楚业务域,才会构建出良好的领域对象、聚合、聚合根、限界上下文等,所以,划分清楚业务域是核心中的核心,望老师答复,是否正确

    作者回复: 理解正确。

    2019-11-13
  • 欧老师你好

    领域类型中“命令”怎么理解?CreatePerson和GetPersonInfo是两个类?DDD提倡使用充血模型,那么Person实体(同样也是聚合根)里会有针对person的CURD方法。CreatePerson和GetPersonInfo里去调用Person里的相应方法?

    作者回复: 命令是一种业务操作或行为,通常会被设计成应用服务或者领域服务,在没有确定是哪种服务之前,统一用命令来表示。实体的方法都在自己的类里面来实现,然后通过聚合根引用来调用。聚合根是一种特殊的实体,它的方法你可以在它的实体内来实现,然后放在领域服务类里面来封装,也可以直接放在领域服务类里来实现。一个领域服务可以是一个类,也可以一个聚合内所有的领域服务放在一个领域服务类里。你可以根据自己的场景来设计,要尽量避免一个类里面的代码过多。

    2019-11-12
  • 张迪
    中台是不是就是微服务之后的产物,之前的微服务太凌乱了,需要中台来聚合一下,是这个意思吗?

    作者回复: 不是的哦。中台是从业务能力复用的角度考虑的。也就是说将可复用的业务能力做成中台。而微服务只是一种架构,业务变成应用的一种架构方式。

    2019-11-11
  • 宝宝太喜欢极客时间了
    示例中是直接划分好的领域跟聚合,老师能不能讲一下领域划分确定的过程以及聚合划分确定的过程,为什么这样划分一个聚合是合理的

    作者回复: 在12节的领域建模里有详细说明。

    2019-11-11
  • 若水
    老师好,我有两个疑问。①、按以上流程分析微服务的划分感觉粒度很小。一个微服务就是一个工程,项目粒度如何决定?②客户也是用户的一种,为什么客户和用户在两个微服务?

    作者回复: 理论上一个限界上下文对应一个微服务。具体拆多细根据企业的微服务的运维能力,如果有云平台,自动化发布和运维工具以及监控等工具,可以按照限界上下文大小来拆分。如果不具备这些能力,建议还是粗一点比较好。
    你说的客户应该是面向个人的客户吧。传统有两类用户,一种是内部用户,另外一部分是个人客户,其中一部分个人客户也是用户。个人客户和用户会有一部分重叠,设计的时候按照客户和用户两个不同的集合来设计,但是部分个人用户来源于个人客户,用户可以引用个人客户的数据。

    2019-11-10
  • 约书亚
    不太了解业务,所以有个疑问哈:
    积分相关的业务原来属于互联网电商的个人领域模型,评级相关的业务则属于传统业务的个人领域模型。为什么二者可以合并成一个评级积分领域模型?是否存在一个应用层的服务,会对评级和积分两个聚合同时进行操作呢?这点从事件风暴中没体现出来啊?

    作者回复: 评级和积分都属于客户增值相关的域,应用服务可以来组合它们的,对外提供客户增值相关的服务。所以将它们放在一个领域模型中。

    2019-11-09
  • 若水
    老师好,这篇中的前端和后端是指业务中面向客户类型是客户还是公司内部成员吗?还是我们开发语言的前端展示页面和后端JAVA开发这种前后端的关系呢

    作者回复: 是你说的第一种情况,从前台和中台的业务角度出发的。前台偏销售支持,中台偏业务支撑。

    2019-11-08
  • 陈耀
    老师,你好。
    想了解下如果互联网保险和传统保险公用一套商品系统,该如何建模?其中商品系统关键元素有 商品 计划 险种 险种 责任 。

    作者回复: 不知道这两种渠道产品在结构上差异大不大?如果差异不大的话,你就可以将它按照中台的模式来构建商品的。把两个渠道产品对应的业务能力合并分析,然后进行业务场景分析,找出实体对象,聚合,建立领域模型。按照分层架构来设计微服务各层的服务,同时给互联网和传统保险提供服务就可以了。

    2019-11-08
收起评论
21
返回
顶部