DDD 实战课
欧创新
人保资深架构师
55517 人已学习
新⼈⾸单¥59
登录后,你可以任选2讲全文学习
课程目录
已完结/共 26 讲
开篇词 (1讲)
DDD 实战课
15
15
1.0x
00:00/00:00
登录|注册

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

新创业务的领域建模
成熟业务的领域建模
体会DDD的整个设计过程
领悟DDD的核心设计思想和理念
DDD设计原则问题
团队DDD的理念和技术能力问题
业务专家或领域专家的问题
DDD学习资料
DDD思想指导中台和微服务设计
微服务内关键对象和依赖关系
微服务的逻辑和物理边界
领域建模
跨越坑和大海
再次感谢
用好DDD的关键
实践中的困难
书籍推荐
专栏内容
坑和大海的跨越
高手的定义
DDD实践和架构设计
经验、方法和设计思想
中台和微服务设计
自我提升
专栏筹备
欧创新
结束语

该思维导图由 AI 生成,仅供参考

你好,我是欧创新。
这是本专栏的最后一讲了,非常感谢你这两个月的陪伴,也非常感谢你的意见和建议。加上前期的专栏筹备,前前后后也有半年了,这半年其实也是自我提升的过程,通过专栏,我将原来不成体系的经验、方法和设计思想,整理成了中台和微服务设计的系统的理论和知识体系。
在撰写专栏时,我站在架构师的角度,尽力将我在实践过程中的经验、思考和体会,以及原创案例等全面详细地呈现给你。希望能够对你的 DDD 实践和架构设计有所帮助,也希望你能快速成长为具有企业级战略视角的架构师和 DDD 设计大师。
那说到成长,相信我们每个人的轨迹都是独特的,但有一点,你一定和我有同样的体会。那就是“所谓高手,就是跨过坑和大海!”每一步都是积累,每一步都是经验,每一步都算数!所以啊,在本专栏的最后,我还是要分享一些干货给你,也是我曾经踩过的一些坑。
很多人接触 DDD,可能是从 DDD 战术设计开始的,因此不知道如何开始 DDD 实践。这个专栏开启后,咱们就可以从领域建模开始了。有了领域模型,我们就可以划分出合理的微服务的逻辑和物理边界;也是因为有了它,我们才能识别出微服务内各关键对象,并建立它们之间的依赖关系,然后开始微服务的设计和开发。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

这篇文章以“结束语 | 所谓高手,就是跨过坑和大海!”为题,由欧创新撰写。文章总结了作者在过去半年中通过专栏整理的中台和微服务设计的系统理论和知识体系,并分享了一些干货和经验。作者强调了在实践DDD时可能遇到的困难,包括业务专家参与、团队DDD理念和技术能力、DDD设计原则等问题,并提出了自己的看法和解决方法。最后,作者表达了对读者的感谢和祝愿。 文章突出了对DDD实践中的困难和解决方法的讨论,强调了作者的实践经验和对读者的帮助。同时,作者还提供了几本与专栏互补的书籍推荐,为读者提供了进一步学习的方向。整体而言,这篇文章为读者提供了有关中台和微服务设计实践中的经验分享和问题解决的内容,对于正在进行相关实践的读者具有一定的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《DDD 实战课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(48)

  • 最新
  • 精选
  • 冬青
    置顶
    git地址以及示例代码讲解预计元旦前后更新,敬请期待!感谢等待、追更!
    2019-12-26
    4
    17
  • David
    讲的很不错,想了解一下幂等和事务方面在ddd实现中有什么思路或经验

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

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

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

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

    作者回复: 江湖再见!

    2019-12-02
    2
    7
  • quietwater
    talk is cheap show me the code

    作者回复: 马上就有代码详解上新了。

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

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

    2019-12-02
    2
  • myking
    老师您好。听完了你的课程后我有个疑问。比如是一个应用授权的系统。 应用 下有多个菜单 可以将菜单分配给多个租户下的角色 角色可以分配给多个人 1、作为一个管理员,希望删除应用时候,需要将应用的菜单及分配的权限一并清理掉 2、作为一个管理员,希望删除应用菜单时候,需要将分配的权限一并清理掉 这种情况我如何去设计删除的这个功能的领域呢?

    作者回复: 你这个场景将应用、菜单和权限放在一个聚合中可以解决。在这个聚合中应用是聚合根,菜单和权限作为实体,被应用聚合根引用。当然,这个权限不可以跨多个应用,而且权限和菜单之间也会有引用的关系。当应用聚合根删除时,被它引用的实体自然就会被删除了。你可以通过应用聚合根来管理聚合内的菜单和权限的生命周期。

    2020-09-20
    2
    1
  • 风之子
    Cqrs架构和分层是一样的吗

    作者回复: 不太一样哈。cqrs是读写分离模式,是对复杂查询的补充。

    2020-05-31
    1
  • coke7up
    一路追下来,没迷路。谢谢老师。

    作者回复: 谢谢

    2020-03-31
    1
  • stg609
    请教老师,关于DDD业务方面的配置如何处理? 比如有 保险, 银行 两个领域,及一个配置中心。那和保险紧密相关的业务方面的配置参数,如一些保费费率,是由配置中心统一维护? 这些带有业务意义的配置如果直接有该领域自己维护是否更合适?

    作者回复: 配置信息属于弱领域模型,不好建立领域模型,但是他们大多是查询,而且实体之间独立性强,如果考虑复用,建议采用CQRS模式,或者也可将他们放在跟领域模型在一起的微服务内,用一个虚拟的聚合将他们聚在一起。

    2020-03-26
    1
收起评论
显示
设置
留言
48
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部