11 | DDD实践：如何用DDD重构中台业务模型？
该思维导图由 AI 生成，仅供参考
传统企业应用分析
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文以保险行业为例，对比分析了互联网电商平台和传统核心应用的业务功能，指出了核心能力的重复建设、通用能力的重复建设、业务职能的分离建设以及前后独立建设等问题。文章提出了中台的设计思想与“高内聚、低耦合”的设计原则，并指出了构建可复用的中台业务模型的方法。建议将重复的通用能力、核心能力沉淀到中台，将分离的业务能力重组为完整的业务板块，构建可复用的中台业务模型。文章强调了站在企业高度，建立前、中、后台边界清晰，融合协作的企业级可复用的业务模型的重要性。文章介绍了如何构建中台业务模型，包括自顶向下和自底向上的建模策略，并以互联网电商和传统核心应用的业务域为例，详细阐述了构建中台业务模型的具体步骤和方法。通过对比分析和重组领域模型，文章展示了构建中台业务模型的过程，强调了领域模型的重组和聚合，以及中台业务模型的微服务设计。文章深入剖析了中台业务模型的构建方法，为传统企业中台转型提供了有益的指导和思路。
《DDD 实战课》，新⼈⾸单¥59
全部留言(50)
- 最新
- 精选
深山小书童接触ddd的概念也蛮多年了，确实如老师所说，微服务的兴起让大家有自然的想起了ddd。但是要将ddd落地，不知道在代码层面如何去分层是最让人困扰的。以java web开发为例，controller，dao，service怎么和应用服务，领域服务，聚合等对应起来呢？老师能不能展示一下框架里面怎么去组织这些概念，这样作为研发人员会比较好理解。ddd的经典三本书里面就是缺少这种东西，互联网小厂由于能力有限很难将其理解和落地。一直期待一门课从代码层面开始自底向上来讲解ddd，反而会更好理解。一直反复讲ddd的好处，感觉浮在表面。作者回复: 其实DDD的核心思想是在于划分领域边界从而来解耦。我认为领域模型才是DDD在微服务设计的关键，只有构建了边界清晰的领域模型的边界，才有可能设计出高质量的微服务。在建立领域模型后，微服务内部可以用DDD战术设计方法，传统的开发方法也不是不可以，有时候在性能方面表现更优秀。 后面我有一节专门讲解这些对象之间是如何协作的，另外也有一讲来介绍DDD的代码目录结构和模型。
2019-11-081147
墨名次DDD是中台、微服务的产品经理作者回复: 比喻很形象！
2019-11-09327- 小毅建议老师，多讲讲怎么做的领域、聚合根、实体的划分，讲讲实施层面怎么做的？而不是直接抛出你最终的结果，我觉得这才是要学DDD的精髓。看到现在知道了很多名词，但是依然并不知道DDD具体如何实施，具体场景下拿什么依据作为划分和聚类的参考~ 建议对于文章中的例子，比如您举的保险类例子，可以多补充些业务背景，这样才能在战术层面搞明白实施和落地的流程，而不是悬浮在半空中~
作者回复: 这一节信息量比较大，后面小的案例里有介绍。
2019-11-0821 
蜗牛慢慢爬看了11个课程了，最大的疑问就是怎么划分？ 老师每次都拿出你已经划分好的领域，感觉很空泛，领会不到精髓作者回复: 这一节的内容有点多，没有做过细的分析，你可以看下一节哈。第12节有详细的领域建模分析过程。
2019-11-1113
祥敏看来要公布Github的仓库了，要不怎么是实践篇@@@作者回复: DDD用于微服务设计的关键就是先建立领域模型，有了边界清晰的领域模型，才能设计出高质量的微服务。在微服务设计时不能脱离领域模型来谈微服务。它们两者之间是必不可少的前后贯通的关系，可能开发人员只关心用DDD来做微服务的开发，并不关心领域建模。领域建模就是DDD的战略实战。而且这种战略设计和分析过程比战术设计更重要。
2019-11-0824
日月星辰感觉这里说的中台就是各个微服务嘛，之前一直觉得中台是一些通用业务的集合，是不会跟数据库直接交互的。那现在这样理解就是说中台也可以跟数据库直接交互了吗？作者回复: 中台是偏业务架构的，一个中台可能会有多个限界上下文，一个限界上下文可以构建一个领域模型，一个领域模型可以设计为一个微服务。当然在进行中台领域模型设计的时候，会考虑通用业务能力的复用。中台会完成业务建模，然后才是微服务按照中台的领域模型完成落地，它们是两个不同阶段的东西，最终与数据库交互的是微服务。
2020-05-2953
信了前端个性能力归前端，后端管理能力归后台。建立前、中、后台边界清晰，融合协作的企业级可复用的业务模型。文中所说前端个性能力具体是什么？后端管理能力又是什么？前、中、后台边界清晰，这三个的边界怎么定义的？越来越模糊了，求解答？？作者回复: 首先采用微服务后，前后端就分离了，前端面向应用，后端主要是领域模型和业务逻辑。 前端主要是面向用户的一些页面操作或者业务流程，不同渠道的用户可能会需求和操作要求不一样，这一部分的变化就由前台应用来控制。后端主要实现业务逻辑和业务管控要求，只有涉及到业务逻辑变化的时候，才会调整中台和后台的业务逻辑。前台需求的变化，在前台调整完成，业务逻辑相关的需求变化在中台和后台完成，他们之间还有应用层的应用服务的编排，进一步隔离前台需求对中台和后台业务逻辑的影响。
2020-03-2023
瓜瓜聚合内的实体都是通过聚合根来进行访问的，这个有没有相关的例子，感谢老师作者回复: 聚合根内会定义引用的实体，在聚合根内部直接使用引用的实体属性或者方法就可以了。 这些实体的方法会被封装成领域服务或者应用服务。外界不需要关心这些实体内的属性或者方法实现了。
2019-11-241
abc-web欧老师好，我说下我对ddd在中台建设中所起作用的看法，不当之处请指点；ddd为中台所涉及到的领域模型梳理提供了方法指引，并对微服务的划分提供了参考标准；但有了这些对一个业务中台的建设还不是完备的；因为中台提供了业务能力服用层，也就是说抽象出了可服用的公共能力，但每个使用该能力的场景是不一样的，这样在该能力上的定制需求的满足是就出现了，这就需要中台有扩展能力，来适应这些需求；所以中台建设不单是微服务的合理拆分，可扩展能力的架构设计也是中台建设的关键；作者回复: 是这样的。
2019-11-131- 若水老师好，我有两个疑问。①、按以上流程分析微服务的划分感觉粒度很小。一个微服务就是一个工程，项目粒度如何决定？②客户也是用户的一种，为什么客户和用户在两个微服务？
作者回复: 理论上一个限界上下文对应一个微服务。具体拆多细根据企业的微服务的运维能力，如果有云平台，自动化发布和运维工具以及监控等工具，可以按照限界上下文大小来拆分。如果不具备这些能力，建议还是粗一点比较好。 你说的客户应该是面向个人的客户吧。传统有两类用户，一种是内部用户，另外一部分是个人客户，其中一部分个人客户也是用户。个人客户和用户会有一部分重叠，设计的时候按照客户和用户两个不同的集合来设计，但是部分个人用户来源于个人客户，用户可以引用个人客户的数据。
2019-11-1021
