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

结束语 | 所谓高手,就是跨过坑和大海!

欧创新 2019-12-02
你好,我是欧创新。
这是本专栏的最后一讲了,非常感谢你这两个月的陪伴,也非常感谢你的意见和建议。加上前期的专栏筹备,前前后后也有半年了,这半年其实也是自我提升的过程,通过专栏,我将原来不成体系的经验、方法和设计思想,整理成了中台和微服务设计的系统的理论和知识体系。
在撰写专栏时,我站在架构师的角度,尽力将我在实践过程中的经验、思考和体会,以及原创案例等全面详细地呈现给你。希望能够对你的 DDD 实践和架构设计有所帮助,也希望你能快速成长为具有企业级战略视角的架构师和 DDD 设计大师。
那说到成长,相信我们每个人的轨迹都是独特的,但有一点,你一定和我有同样的体会。那就是“所谓高手,就是跨过坑和大海!”每一步都是积累,每一步都是经验,每一步都算数!所以啊,在本专栏的最后,我还是要分享一些干货给你,也是我曾经踩过的一些坑。
很多人接触 DDD,可能是从 DDD 战术设计开始的,因此不知道如何开始 DDD 实践。这个专栏开启后,咱们就可以从领域建模开始了。有了领域模型,我们就可以划分出合理的微服务的逻辑和物理边界;也是因为有了它,我们才能识别出微服务内各关键对象,并建立它们之间的依赖关系,然后开始微服务的设计和开发。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DDD实战课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(26)

  • 阿玛铭
    故不积跬步,无以至千里。不积小流,无以成江河。建议老师会说话就出书。这个课程比较全面,包含价值观和方法论两个层面的内容。一是课程订阅者可以作为工具书温习复习,二是私人癖好想收藏记录一下。

    作者回复: 谢谢你的建议。等好了告诉你哈。

    2019-12-02
    4
  • David
    讲的很不错,想了解一下幂等和事务方面在ddd实现中有什么思路或经验

    作者回复: 就DDD来说,它是没有幂等的方案的,需要我们通过设计来实现。原本想在第20节加一个幂等的议题的。

    你可以在不同阶段进行幂等性处理,如使用Token(UUID)、分布式锁、去重表等方式。
    可通过Token或全局唯一ID确定请求的唯一性:根据业务生成一个全局唯一ID,在调用接口时会传入该ID,接口提供方会从相应的存储系统比如Redis中去检索这个全局ID是否存在,如果存在则说明该操作已经执行过了,将拒绝本次服务请求;否则将相应该服务请求并将全局ID存入存储系统中,之后包含相同业务ID参数的请求将被拒绝。
    可使用Redis分布式锁解决资源并发竞争的情况,获取唯一请求;
    可使用去重表保证数据库数据唯一:适用于在业务中有唯一标识的插入场景。比如在支付场景中,一个订单只会支付一次,可以建立一张去重表,将订单ID作为唯一索引。把支付并且写入支付单据到去重表放入一个事务中,这样当出现重复支付时,数据库就会抛出唯一约束异常,操作就会回滚。这样保证了订单只会被支付一次。

    2019-12-03
    2
  • 陈华应
    从专栏出来一篇没有落下的跟到现在,时间真的好快!
    收获良多,算是入了ddd的门,重术(战术)更要重道(战略),后续打算把ddd分享给身边的人,至少一起码的人要有所了解,有相同的语言,才能一起聊下去
    感谢老师,江湖再见!!!

    作者回复: 江湖再见!

    2019-12-02
    1
    2
  • Geek_aa8017
    老师,git项目地址什么时候可以整理好发出来啊

    作者回复: 正在准备中,等整理好了发出来。

    2019-12-11
    1
  • 瓜瓜
    老师的代码什么时候放出来啊。

    作者回复: 最近比较忙哈,还需要一点时间。等好了告诉你。

    2019-12-10
    1
  • marker
    很希望老师能多出一些领域分析实战的相关课程,四色原型,用列,事件风暴这些相关设计

    作者回复: 谢谢建议。后续考虑考虑。

    2019-12-09
    1
  • 祥敏
    欧老师的课程内容富有层次,注重整体。
    不能一下子都吸收,后序要反复实践、归纳整理,如此循环才能跨过坑和大海。

    作者回复: 谢谢,建议来回多看几遍。

    2019-12-04
    1
  • 墨名次
    第一次学习这种几乎纯理论的课程确实很考验耐心,幸运的是老师这种讲课方式很适合我,全部学习了,收获很大,感谢!

    作者回复: 谢谢你的耐心陪伴。

    2019-12-02
    1
  • 达文西
    粗劣看完了,实在都是干货,值得反复多看几遍.等老师的代码demo出来再对照着看相信收获更大.
    2019-12-17
  • 瓜瓜
    另一个问题帮忙回复下?战术设计完成映射,战略设计完成领域建模,这个回答太笼统了,你文章里面写过了,占用您点时间,帮忙看一下另一个问题呢,感谢

    作者回复: 已回复。因为不知道你的聚合是如何得来的,不知是否回答清楚?

    2019-12-07
    2
  • 瓜瓜
    具体也就是,是放在战略设计阶段还是放在战术设计阶段的“建立领域模型与微服务模型的映射关系”这一过程中

    作者回复: 战术设计来完成映射。战略主要是领域建模。

    2019-12-07
  • 瓜瓜
    老师,您好,现在在做一个开放平台(包括openapi)的系统,在战略设计的时候,有个地方有点疑惑,主要是,用户申请调用接口的权限和回调接口的权限这块,我是给统一画到“权限”限界上下文中了,该权限上下文中包含“接口权限申请、修改、删除”聚合,“回调接口权限申请、修改、删除”聚合,此处在战略设计阶段是否要抽象出“权限的申请、修改、删除”这一聚合(为接口和回调接口权限的公共抽象)。也就是该限界上下文中是只包含两个聚合(接口权限和回调接口权限),还是三个聚合(权限、接口权限、回调接口权限),根据第十二节中业务场景分析“找出领域事件、实体和命令等领域对象,支撑领域建模。”,感觉分成三个是更好的选择,望老师指正,在线急等。。。

    作者回复: 这两个聚合实体之间业务行为差异大不?不大的话,我建议你将这两个聚合合并,变成一个领域模型。如果差异实在太大,还是分成两个聚合比较好。如果是三个聚合,三个聚合的实体对象如何聚合在一起?是把公共的实体独立出来吗?

    2019-12-07
    5
  • Rick
    在微服务拆分的时候遇到一个问题。比如订单实体中有一个用户id字段来表示买家是谁。那假如在界面上显示订单的时候需要显示买家的昵称,而且如果用户修改了昵称,希望该用户所有未完成的订单上都显示修改后的昵称。并且如果用户存在未完成的订单则不允许用户删除自己的账户。这个时候如果把用户服务和订单服务拆分的话,应该怎样保证数据的一致性呢?拆分之后,用户服务的删除操作依赖于订单服务告诉它该用户是否存在未完成的订单。而订单服务又依赖于用户服务去获取用户的昵称。这样就相互依赖了。不知道老师怎么解决类似的问题呢?

    作者回复: 如果用户和订单在一个微服务内,就需要应用服务来协调和校验。如果是微服务之间,可以通过BFF微服务或者各自的应用服务来编排和校验。

    2019-12-04
  • 你的美
    感谢欧老师以后再见!

    作者回复: 再见,有问题咱们还可以探讨。

    2019-12-03
  • zzzzzmh
    想了解一下,fatcory 和 repository 都可以构建 domain object,这两个分别是什么

    作者回复: 仓储是专门与数据库打交道的,用于持久化数据。而工厂是用于复杂聚合的实体数据初始化,简单的聚合可以通过聚合根直接在构造函数中完成初始化,而复杂聚合则交给工厂来完成聚合实体数据的初始化,工厂不参与业务逻辑处理。两者差不多是一前一后的关系。

    2019-12-03
    5
  • 云中漫步
    感谢,一定还会反复学习这门课程。

    作者回复: 多看几遍,仔细体会和思考,确实是感受到DDD的思想的。

    2019-12-03
  • LS
    感谢

    作者回复: 感谢陪伴

    2019-12-03
  • 要文有文要武有武
    DDD划分微服务边界;
    DDD对企业大中台建设的指导价值,中台和平台的区别;
    DDD的战略设计和战术设计;

    感谢老师的辛勤付出,还会回看,也希望有机会在公司践行DDD文化和思想。

    作者回复: 谢谢,DDD体系还是挺大的,需要慢慢体会,琢磨。

    2019-12-02
  • Kian.Lee
    从14年接触 DDD ,并先后3次在生产实践中打造适合自身的 DDD 框架,越到后面招式的束缚越少,最后终于打造出了“嗯,就是她了”的框架,再系统的听欧老师讲一遍算是为这些年的 DDD 所学做了一次迟来的总结😀

    作者回复: 悟道了哈。

    2019-12-02
    2
  • 张迪
    不舍啊! 感觉还要在看几遍。

    作者回复: 多看几遍吧,DDD体系太大,有时候篇序组织起来有点费劲,需要前后结合来看,来理解。

    2019-12-02
收起评论
26
返回
顶部