DDD实战课
欧创新
人保高级架构师
立即订阅
4911 人已学习
课程目录
已完结 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实战课
登录|注册

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

欧创新 2019-11-25
你好,我是欧创新。
为了更好地理解 DDD 的设计流程,今天我会用一个项目来带你了解 DDD 的战略设计和战术设计,走一遍从领域建模到微服务设计的全过程,一起掌握 DDD 的主要设计流程和关键点。

项目基本信息

项目的目标是实现在线请假和考勤管理。功能描述如下:
请假人填写请假单提交审批,根据请假人身份、请假类型和请假天数进行校验,根据审批规则逐级递交上级审批,逐级核批通过则完成审批,否则审批不通过退回申请人。
根据考勤规则,核销请假数据后,对考勤数据进行校验,输出考勤统计。

战略设计

战略设计是根据用户旅程分析,找出领域对象和聚合根,对实体和值对象进行聚类组成聚合,划分限界上下文,建立领域模型的过程。
战略设计采用的方法是事件风暴,包括:产品愿景、场景分析、领域建模和微服务拆分等几个主要过程。
战略设计阶段建议参与人员:领域专家、业务需求方、产品经理、架构师、项目经理、开发经理和测试经理。

1. 产品愿景

产品愿景是对产品顶层价值设计,对产品目标用户、核心价值、差异化竞争点等信息达成一致,避免产品偏离方向。
事件风暴时,所有参与者针对每一个要点,在贴纸上写出自己的意见,贴到白板上。事件风暴主持者会对每个贴纸,讨论并对发散的意见进行收敛和统一,形成下面的产品愿景图。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DDD实战课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(28)

  • 盲僧
    新哥,把代码放到git上给兄弟们个地址吧

    作者回复: 我需要时间整理一下哈,等好了再共享。

    2019-11-25
    1
    7
  • zj
    我觉得老师可以讲一下CQRS,毕竟微服务好多都是要查询的哈哈

    作者回复: CQRS其实就是读写分离,主要解决DDD的复杂查询问题。一般是写库和读库分离,但是实效性不容易保证。其实你也可以在同一个库,用领域或者应用查询服务来完成复杂查询的。

    2019-12-01
    2
  • zj
    推广活动为一个聚合,直播推广为一个聚合,但是这两个聚合之间又是有联系的,比如直播推广可以参与推广活动。那这样这个命令到底属于哪个聚合呢?还是说将推广活动作为一个值对象呢

    作者回复: 聚合内有实体吧,看看这些实体跟那个聚合根关联紧密,生命周期归聚合根管理,就放在跟聚合根在一起的聚合内,如果别的聚合要用,有两种方案,第一种是通过聚合根引用实体。第二种方案,在另外的聚合内将这个实体设计为值对象或者实体,值对象或实体的数据来源于另外的那个聚合的实体。

    2019-11-26
    1
  • Alex zhang
    老师,代码有github链接吗

    作者回复: 本来没准备放代码的哈,我后面花时间整理一下吧。

    2019-11-25
    1
    1
  • 番茄炒西红柿
    问一下老师,关于ddd读写那块,我最近看到有的文章说在ddd化为微服务中最好做到读写分离,将读的逻辑放在service(domain层的),写和其他的逻辑放在entity中,但这里会遇到spring di问题,entity不方便做di,我看的两种方法一种是通过entity的工厂类来实现实体的di,另一种是同一用repository工程类来注入。是否还有更好的方法,还有这种读写是否适合ddd(因为我自己适着用充血模型来写也发现很多时候复杂的读逻辑不适合放在entity中实现)

    作者回复: 复杂的查询建议独立出来,通过CQRS来实现,可以根据时效性要求设计为读写同一个库或者读写库分离的方式,复杂的查询逻辑可以独立为应用或者领域服务。复杂聚合的实体初始化建议用工厂类服务,简单的直接用构造函数就可以了。

    2019-12-15
  • 电商小能手
    老师,请假单在请假聚合里,审批人在人员组织关系聚合里,在请假单聚合根(leave.java?)是如何通过人员组织关系聚合根(Person.java)关联引用到审批人的信息的?是leava对象里有Person对象吗,然后通过Person对象导航到审批人信息?
    2019-12-15
  • 电商小能手
    "DO 是实体和值对象的数据和业务行为载体,承载着基础的核心业务逻辑。通过 DO 和 PO 转换,我们可以完成数据持久化和初始化。"“第二步:提交审批facde实现DTO转DO”一直不理解不了DO对象,老师,你可以结合这章的内容,代码说明下DO对象吗?这个DO对象应该放在项目结构哪个目录下?
    2019-12-15
  • alex
    有没有一个基于 DDD 设计实现的实际可用的开源项目可以分享下

    作者回复: 正在准备,好了会通知大家的。

    2019-12-10
  • 鬼谷学徒
    老师,你好。对比MVC结构,controller在DDD分层架构中分到哪一层?在课程的代码目录节奏中没有看到呢?是不需要了吗?如果需要代码目录要如何设计?

    作者回复: 在DDD里面没有提到controller这个概念。按照分层理论,它承担应用服务与前端应用适配的工作,感觉应该是属于基础层或者用户接口层。

    2019-12-10
  • 要文有文要武有武
    审批规则值对象有查询审批规则方法?这里不是很明白。
    不应该通过领域服务或者聚合根来做查询吗?这里的值对象是充血模型?
    望老师回复。

    作者回复: 审批规则有两个,一个是审批规则的配置数据,独立存在。另一个是保存在请假单上的审批规则,它根据请假基本信息匹配审批规则配置数据后获得,只要请假基础数据不变,你就不需要在每次提交审批的时候去查询审批规则的配置数据。依附于请假单的这个审批规则是值对象。

    2019-12-02
  • HUNTER
    老师可否以电商系统为例,讲解一下是怎么拆分的

    作者回复: 不好意思哈,电商的内部流程我不是太熟悉哦。
    不过不管什么样的业务,你最终目的就是为了找出命令、实体等领域对象,然后构建聚合和限界上下文。
    你可以通过场景分析,模拟一个人在系统中的旅程,去分步骤操作就可以了。

    2019-11-28
  • 深山小书童
    老师好,请问场景分析是不是按角色来分,每一个场景不涉及多个角色?例如请假场景只是罗列了请假人从创建到提交审批的动作。我们一般讲请假流程的话、提交审批之后会根据审批结果进行下一步动作,比如审批者审批拒绝,那么请假者修改请假单再次提交审批,这种情况对于请假人是不是要加一个场景。我的疑问就是,老师说的场景和一般的流程有什么区别?我的理解是流程会涉及多个角色的动作,场景只是一个角色的动作。请多多指教

    作者回复: 可以多场景多角色,主要目的是找出所有的命令和实体对象。只要能达到这个目的,可以采用多种方法。

    2019-11-27
  • 瓜瓜
    上级审批领导来源于人员聚合根,可设计为值对象。 有两个问题:1.上级审批领导为什么是值对象呢?2.已经有了组织关系了,为什么还要有上级审批领导呢?这样不就重复了吗?

    作者回复: 组织关系是一个实体,记录人员关系和上级领导,上级领导数据来源于人员聚合根,所以设计为值对象。

    2019-11-26
  • 观弈道人
    欧老师,你在实践中,一般是如何从资源库加载数据,即是领域实体还是领域服务调用资源库加载数据?

    作者回复: 通过聚合根来调仓储服务。用仓储服务来实现数据的初始化和持久化。大批量的数据查询建议用CQRS模式。

    2019-11-26
  • 瓜瓜
    场景分析中,“提交下一步审批”这一步是不是不应该这样(当然这样也没有问题),是不是根据“审批”业务流,产生的审批事件自动决定是到最后一步了,还是继续下一步审批,因为审批人只需要关心自己的审批就可以了,不要关心是否还有一下审批人(也就是不需要点击“发往下一个审批人”),也样流程更合理,页面也更清晰,望老师指正

    作者回复: 这个是系统内部判断的,根据审批规则和当前审批人的角色来确定是否还有下一审批,如果有则获取下一审批人和角色,给请假单分配下一审批人。

    2019-11-26
  • Farewell丶
    有时候为了完成领域层的业务设计,有的实体对内部属性的访问进行了控制,但是在仓储接口存储的时候又需要持久化下来,这时候该怎么做呢?

    作者回复: 不了解你说的“访问进行了控制”是什么意思?是别的层访问不了吗?
    其实你把DO实体传给仓储接口就可以了,仓储实现内部会将DO映射成PO对象,然后PO对象就可以实现持久化了。

    2019-11-26
  • zj
    有个场景请教一下,推广活动是一个聚合,直播推广计划是一个聚合。那直接推广报名参加推广活动这个命令应该写在那个聚合里呢?

    作者回复: 你先要按照步骤根据命令找出实体来,然后定义实体在哪个聚合,实体的命令自然就会有他的聚合了。

    2019-11-26
    2
  • 川杰
    审批规则,这个被设计为值类型,这个可以理解;但是如果我要对审批规则做增删改,怎么设计比较合理?在请假领域里新增一个:LeaveApproveRuleService,里面加上增删改的方法,可以吗?(其实就是传统的方式)

    作者回复: 可以的。不必纠结于聚合根。聚合根的目的是为了保证聚合内的数据一致性。审批规则内不会出现这种请假。你可以用领域服务或者实体的方法。

    2019-11-26
  • 乘风
    请问确定实体的关键是什么?为什么组织关系是实体而非值对象?

    作者回复: 这里一个人可能会有多级组织关系,比如项目经理,处室领导,部门领导等等。中间还会查询过滤,所以设计为实体。

    2019-11-26
  • 宝宝太喜欢极客时间了
    老师,图用什么工具画的

    作者回复: visio

    2019-11-25
收起评论
28
返回
顶部