如何落地业务建模
徐昊
Thoughtworks 中国区 CTO
24830 人已学习
新⼈⾸单¥68
登录后,你可以任选2讲全文学习
课程目录
已完结/共 32 讲
如何落地业务建模
15
15
1.0x
00:00/00:00
登录|注册

01|领域驱动设计到底在讲什么?

用于传递精粹的知识
形成团队的统一语言
反映软件实现的结构
统一语言与模型关联
知识消化的重点
DDD的核心过程
修改模型就是修改代码
通过聚合关系表达业务概念
贫血模型 vs. 富含知识的模型
头脑风暴与试验
精炼模型
开发富含知识的模型
基于模型提取统一语言
关联模型与软件实现
业务系统中构造与业务强相关的模型
模型驱动的设计方法
领域模型的用途
Eric Evans的名著“Domain Driven Design:Tackling the Complexity in the Heart of Software”
模型驱动的设计方法
领域驱动设计(DDD)
小结
模型与软件实现关联
知识消化的五个步骤
领域模型对于业务系统的选择
概述
领域驱动设计

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

你好,我是徐昊。今天我们来聊聊领域驱动设计(Domain Driven Design,即 DDD)。
说起业务建模,领域驱动设计是一个绕不过去的话题。自从 Eric Evans 在千禧年后发布他的名著“Domain Driven Design:Tackling the Complexity in the Heart of Software”,领域驱动设计这一理念迅速被行业采纳,时至今日仍是绝大多数人进行业务建模的首要方法。
有意思的是,可能因为成书年代过于久远,大多数人并没有读过 Eric 的书,而是凭直觉本能地接受了领域驱动这一说法,或是在实践中跟随周围的实践者学习使用它。但是对于 Eric 到底在倡导一种什么样的做法并不了然
所以今天这节课,我们要回顾一下领域驱动设计的要点和大致做法,从而可以更好地理解 DDD 从何处而来,以及 DDD 在其创始人的构想中是如何操作的。

领域模型对于业务系统是更好的选择

我们都知道,软件开发的核心难度在于处理隐藏在业务知识中的复杂度,那么模型就是对这种复杂度的简化与精炼。所以从某种意义上说,Eric 倡导的领域驱动设计是一种模型驱动的设计方法通过领域模型(Domain Model)捕捉领域知识,使用领域模型构造更易维护的软件。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

领域驱动设计(DDD)是一种模型驱动的设计方法,旨在捕捉领域知识,构建易维护的软件系统。文章强调了领域模型对业务系统的重要性,并介绍了知识消化的五个步骤,构成了一个提炼知识的循环。作者强调了领域驱动设计的重要性,以及知识消化的方法对领域模型的提炼和完善。此外,文章还讨论了模型与软件实现的关联,从贫血模型到富含知识的模型的转变,以及通过聚合关系表达业务概念的重要性。通过这些讨论,读者可以了解到领域驱动设计的核心理念和实践方法,以及如何构建更具表达力和易维护性的领域模型。知识消化是一种迭代改进试错法,通过迭代反馈的方式逐渐提高模型的有效性。这个过程的前提是将模型与软件实现关联在一起。文章还提到了领域驱动设计的核心过程,即统一语言与提炼知识循环,强调了其重要性。文章最后提出了一个思考题,引发读者对领域驱动设计的深入思考。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《如何落地业务建模》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(57)

  • 最新
  • 精选
  • Jxin
    置顶
    课后题,个人YY: 1.文中其实没有对“统一语言”下定义。但以我的认知,“统一语言”是什么,确实不好明确定义,它并非一种固定格式的交付物,而是贯穿整个领域驱动设计时的多种元素。是沟通时达成共识的桥梁;是圈定限界上下文时划分聚合的依据;是设计领域模型时定义模型的参考;甚至是命名类名方法名的标准。 2.所以,与文中不同的是,我不认为是根据模型(领域模型)提取的统一语言。而是通过领域场景(这也算模型呀)分析,提炼出领域知识,共建整个系统的统一语言,而后才是建模(领域模型)。 3.如此一来,就是先有统一语言再有领域模型(之后还会相互影响,但感觉开始是这个顺序)。领域模型的抽象依赖统一语言做指导(类似于设计原则,在迷茫时引导你做决策)。如此,统一语言有它必须存在的价值在,所以不能拿掉。 4.那业务方可不可以直接使用模型?不可以,因为如果业务方直接使用模型,那么不管是知识的诅咒还是选择性偏见都可能促使业务方在讨论统一语言时,迁就或者受制于已有模型。这样在软件持续发展中,不利于统一语言的迭代(或则说掐死了很多可能性?)。 5.综上所述: 一个人脑袋里要同时有多个观点,并保持它们各自独立迭代发展是很难的。但有不同的几波人各自拿一个观点,然后再讨论合并,这样出来的统一语言相对应该会更客观些吧。不让业务方直接用模型也许是不想影响他们那波人脑袋中的观点吧。 问题: 案例里:“订阅”也只能表示专栏信息。感觉不大合适。 专栏多半是独立的聚合,毕竟专栏可以独立展示,订阅,做活动,这些行为都说明专栏有“完全民事行为能力”,所以它应该是个独立的聚合。所以用户维度的“订阅”应该是两个聚合的关联关系。失去用户,“订阅”是无法独立存在的概念,自然也不能表示任何东西。

    作者回复: 问题在后续课程里有解释。至于先有模型还是先有统一语言,这里有区别 就是统一语言提案和统一语言是有区别的,第二课会讲

    2021-06-24
    4
    13
  • garlic
    业务操作模型的话,会导致模型和软件割裂,最终变为分析模型。更可怕的是一天一个想法,搞不好搞出百八十个模型都有可能。统一语言起到了屏蔽隔离保护作用,有点像网络分层,具体模型和软件实现由开发人员选取合适的方式实现。

    作者回复: nice

    2021-06-24
    34
  • Oops!
    不是很理解文中的例子,按例子说的设计方式,模型User要聚合不同业务场景下的不同实体,去订单、浏览记录、评论等,这样一个user模型不会变成巨无霸了吗?还是说,不同领域下都有自己的user模型,每个领域下的user模型聚合的实体都不一样?比如售卖领域,有名为User模型,他聚合了订单这个实体。评论领域,也有个名为User的模型,聚合了评论,提供了发布评论的接口?如果是这样的话,实际代码实现上,会不会出现大量的相似的重复的数据结构呢?比较困惑。

    作者回复: 等看第6课 可以解决你的问题

    2021-06-24
    7
    23
  • 锤他
    思考题: 个人认为根本原因是需要团队协作。首先模型是需要迭代的,迭代通常业务和技术一起讨论,讨论时每个人因为角色/背景/团队等的差异,会对同一个模型产生不同的理解。 通过统一语言,可以把对模型的认识和理解的差异消除。

    作者回复: good point

    2021-06-24
    2
    10
  • Geek_470ca4
    模式是抽象的,没有实体,只能被表达。程序员用代码和文档表达模型,业务人员用统一语言表达模型。

    作者回复: nice

    2021-06-24
    2
    7
  • 我觉得,用统一语言的原因是,模型不好直接用语言描述,一个东西连名字都没有,怎么讨论呢

    作者回复: 这是统一语言的一个作用

    2021-06-24
    6
  • panda
    评论里有一些很牛的总结和想法,值得反复阅读品味,感觉极客时间缺少能让我们收藏的功能,或者统一查看自己点赞过的评论功能!

    编辑回复: nice~反馈给产品经理啦!

    2021-11-07
    5
  • OperaX
    在工作过程中发现,实际上开发人员与业务人员沟通时,业务人员用自己的语言、名词描述自己的问题,开发人员用自己的语言、术语描述解决方案。沟通的过程中,可能开发人员根本就没有听懂问题,业务人员听解决方案更是云里雾里。 如果能把问题提炼成模型,通过模型去沟通,在沟通的过程中大家逐渐统一概念,统一语言。那么之后的讨论就会很快的理解对方的意思,也会得出更准确的解决方案

    作者回复: nice

    2021-07-30
    4
  • 莫太咸
    业务人员直接使用DDL算不算是直接使用模型呢?如果算的话,优点在于,如果模型质量高,DDL简单易用,通过DDL直接使用模型反而能大大提高效率。但缺点是,国内的业务人员有编程思维的人太少;DDL带来的多语言混杂重构调优不易;会有很多重要的领域概念被埋没在DDL的脚本中,导致模型僵化。

    作者回复: 算是一种情况,7-9课有一些解法

    2021-06-25
    4
  • webmin
    同样的字或话语,在不同时代或者不同的地区,因为背景的不一样,可能会具有差别比较大的含义,就连圣经中的上帝都会通过把语言搞得区别开,让人类语言不通无法协作,从而让巴别塔半途而废,由此可见统一语言的必要性。 每个人头脑中对的模型理解,我想就算不是千差万别,也不会是一目了然,再者好多人员并不能把自己的想法书面的表达到让其它人看得懂,这种时候就需要先通过讨论来达成共识,讨论是要有基础的,先统一语言可以避免歧义或鸡同鸭讲。

    作者回复: 共识是重要的产出物

    2021-06-27
    3
收起评论
显示
设置
留言
57
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部