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实战课
登录|注册

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

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

软件架构模式的演进

在进入今天的主题之前,我们先来了解下背景。
我们知道,这些年来随着设备和新技术的发展,软件的架构模式发生了很大的变化。软件架构模式大体来说经历了从单机、集中式到分布式微服务架构三个阶段的演进。随着分布式技术的快速兴起,我们已经进入到了微服务架构时代。
我们先来分析一下软件架构模式演进的三个阶段。
第一阶段是单机架构:采用面向过程的设计方法,系统包括客户端 UI 层和数据库两层,采用 C/S 架构模式,整个系统围绕数据库驱动设计和开发,并且总是从设计数据库和字段开始。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DDD实战课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(66)

  • Geek_a91670 置顶
    事件风暴到底是什么啊?

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

    2019-10-21
    2
  • halweg
    我能说我等极客时间出这个等了1年吗?

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

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

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

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

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

    2019-10-15
    3
  • TH
    DDD是针对业务的,那么到底怎么理解“业务”呢?什么属于业务,什么不属于业务呢?尤其是业务与技术、基础设施、中间件之间的关系怎么划分?

    换句话说,DDD是否适合技术框架、技术平台甚至技术中台的建设呢?比如我要开发一个代码部署系统或者配置管理系统,这样的系统是否适用DDD呢?因为对整个公司来说它们应该属于基础设施层的东西吧。

    DDD是否存在大系统套小系统的形式?比如整个公司业务用DDD来设计,然后业务中的某个子系统也用DDD来设计,它们可以嵌套吗?

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

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

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

    2019-10-25
    2
    2
  • 小明
    为什么soa架构会使得系统变得臃肿,可扩展性和弹性伸缩性差。我们公司以前是soa,也是拆了订单,活动,商品,拼团打折,仓储,物流,会员中心等等服务,我们也没用到总线,webapi包了一层,客户端(安卓,ios,pc)调用,api聚合服务,我想请教下1.这种设计跟微服务的区别.2.可扩展性为什么差了.

    作者回复: 传统SOA架构基本是单体模式,也就是集中式架构。因为需求会越来越多,系统会越来越庞大。系统大了后就不太方便放到容器之类的环境上,只能用weblogic之类的中间件,靠手工来运维了。

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

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

    2019-10-21
    1
  • 咸鱼大翻身
    公司最近也在准备对已有的业务拆分业务领域,希望作者能早点讲实战,对于这块特别是事件风暴方法

    作者回复: 很快就到了,耐心等待哈。

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

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

    2019-10-16
    1
  • 陈华应
    第一个接触ddd的服务是在leader带领下及自己恶补啃ddd砖头书的情况下完成的,收获就是有了点ddd的思想,但是现在对整体和细节都存在理解不清的地方。后面多结合老师的课做回顾和请教~

    作者回复: 一起学习和进步哈。

    2019-10-15
    1
  • 酆友鹏
    听说过,一直不知道怎么去实践DDD

    作者回复: 专栏里面会有详细的过程介绍,先理解概念,然后学会怎么用事件风暴建立领域模型,根据领域模型来设计微服务。等着后面的实战篇哈。

    2019-10-14
    1
  • Leiy
    在开始微服务拆分的过程中,碰到两个问题:
    1.项目组开发人员对业务的理解不同,对于有些聚合是放在哪个限界上下文中会产生分歧
    2.对于一个庞大古老系统,拆分是开始时候就拆分的较细,还是先拆分两个核心业务域,后面再逐步拆分

    作者回复: 很多的时候领域的细分会根据业务流程阶段或者模块功能,这两个方面业务有很好的内聚性,很可能就对应到了子域。如果领域实在太大,你可以考虑将它分成小的领域,然后在这小的领域中去做事件风暴,划分限界上下文,并确定哪些聚合放在哪个限界上下文里,这里领域专家会起到比较大的作用。不过建立领域模型后,你还需要看看其它子域是否有重叠的内容,如果有的话,还需要对领域模型重组。

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

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

    2019-10-14
    1
  • 瓜瓜
    如何用DDD解决复杂业务的架构问题,一直在等这方面的相关课题

    作者回复: 希望能对你有帮助。

    2019-10-14
    1
  •  素丶  
    同等一年

    编辑回复: 姗姗来迟~莫怪莫怪!

    2019-10-14
    1
  • 卡特
    公司不停的在做市场探索,新项目基于微服务架构,基于业务建模,结合团队规模拆分微服务,正缺少相关领域设计理论支持。

    作者回复: 正好可以用上^_^。

    2019-12-09
  • 番茄炒西红柿
    第一章抛出好多名词感觉有点看不懂,希望后面会好点😭

    作者回复: DDD名词是很多,前后稍微多看几遍吧。

    2019-11-22
  • caozhao
    DDD不但可以应用在微服务中,还可以使用在单体应用上,很期待
    2019-11-20
  • krugle
    电商saas 那个是核心域 订单还是 商品

    作者回复: 每个企业都不太一样的,跟商业模式和战略定位有关。个人感觉在电商领域,订单和商品是比较通用的业务能力,偏通用会多一些。

    2019-11-17
收起评论
66
返回
顶部