后端技术面试 38 讲
李智慧
同程艺龙交通首席架构师,前 Intel& 阿里架构师,《大型网站技术架构》作者
37373 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 46 讲
不定期加餐 (1讲)
后端技术面试 38 讲
15
15
1.0x
00:00/00:00
登录|注册

20 | 领域驱动设计:35岁的程序员应该写什么样的代码?

六边形架构
分层架构
需求变更不影响现有代码
业务逻辑一致性
值对象
实体
体现真正的价值
把握领域模型在需求变更中的演进
探索领域驱动设计
深刻的领域理解和认知
领域经验积淀
架构方案
实体设计
子域和限界上下文
从领域出发,分析领域内模型及其关系
优势
领域模型对象
业务逻辑围绕领域模型设计
难以维护
业务逻辑分散
Controller → Service → Dao
职业危机
代码质量下降
需求变更导致冲突
保持优势和地位
大龄程序员的优势
领域驱动设计(DDD)
领域模型模式
事务脚本模式
35岁程序员的挑战
领域驱动设计

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

我在阿里巴巴工作的头一年,坐在我对面的同事负责开发一个公司统一的运维系统。他对这个系统经过谨慎的调研和认真的思考,花费了半年多的时间开发,终于开发完了。然后邀请各个部门的相关同事做发布评审,如果大家没什么意见就发布上线,全公司范围统一推广使用。
结果在这个发布会上,几乎所有部门的同事都提出了不同的意见:虽然这个功能是我们需要的,但是那个特性却是不能接受的,我们以往不是这样的……
最糟糕的是,不同部门的这个功能和那个特性又几乎不相同。最终讨论的结果是,这个系统不发布推广,需要重新设计。
这个同事又花了几个月的时间尝试满足所有部门的不同的需求,最终发现无法统一这些功能需求,于是辞职了……
他离职后,有次会上我们又讨论起这个项目为什么会失败,其中有个同事的话让我印象深刻,他的话的大意是:如果你对自己要开发的业务领域没有清晰的定义和边界,没有设计系统的领域模型,而仅仅跟着所谓的需求不断开发功能,一旦需求来自多个方面,就可能发生需求冲突,或者随着时间的推移,前后功能也会发生冲突,这时你越是试图弥补这些冲突,就越是陷入更大的冲突之中。
回想一下我经历的各种项目,似乎确实如此。用户或者产品经理的需求零零散散,不断变更。工程师在各处代码中寻找可以实现这些需求变更的代码,修修补补。软件只有需求分析,并没有真正的设计,系统没有一个统一的领域模型维持其内在的逻辑一致性。功能特性并不是按照领域模型内在的逻辑设计,而是按照各色人等自己的主观想象设计。项目时间一长,各种困难重重,需求不断延期,线上 bug 不断,管理者考虑是不是要推到重来,而程序员则考虑是不是要跑路。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

领域驱动设计(DDD)是一种面向对象的软件开发方法,旨在解决复杂业务逻辑的实现和需求变更过程中的问题。本文以一个实际案例为例,阐述了事务脚本模式和领域模型模式的区别和优势。事务脚本模式是按照业务处理的过程组织业务逻辑,而领域模型模式则是围绕领域模型设计业务逻辑。领域模型对象充血了行为和数据,通过领域模型对象的交互完成业务逻辑的实现。相比之下,领域模型模式更有优势,特别是在持续的需求变更和业务迭代过程中。通过领域模型分析,可以识别出伪需求,使系统更好地保持一致性,也可以使开发资源投入到更有价值的地方去。因此,对于复杂的业务逻辑实现来说,领域模型模式是更为合适的选择。 领域驱动设计(DDD)是一种解决复杂业务逻辑实现和需求变更问题的面向对象软件开发方法。文章通过实际案例阐述了事务脚本模式和领域模型模式的区别和优势,指出领域模型模式在持续需求变更和业务迭代中更具优势。通过领域模型分析,可以识别伪需求,保持系统一致性,使开发资源投入更有价值的地方。因此,对于复杂的业务逻辑实现来说,领域模型模式是更为合适的选择。

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

全部留言(19)

  • 最新
  • 精选
  • Zend
    记得在老师的一篇文章中说好的程序员的工作效率是一般程序员的10倍甚至更多。好的程序员不仅代码写的漂亮,可维护性强 ,面对需求变动时能更从容面对。那如何做一个好的程序员 我想对领域的理解,对需求的理解 ,具有一定的前瞻性思考,适时提出自己的建设性建议,通过代码让公司的业务系统可持续发展,推动公司业务的增长。

    作者回复: 👍

    2020-01-08
    2
    19
  • Paul Shan
    事务脚本模式的特点在于状态都在数据库里,业务逻辑在service层,业务逻辑与状态完全分离。 领域对象模型,特点是聚合状态和操作,提供相对独立的模块和类。领域的模型的对象之一是实体,有唯一标识,实体被销毁前标识不变,能通过标识获得,实体的状态会变化。领域的另外一种对象是值对象,状态在生命周期内不变,因而更简单。领域对象因为有状态可以表达更为丰富的关系。但是设计好的领域对象依靠的主要不是技术而是对业务的理解。大龄程序员选择的业务领域的余地还是越来越小的,可能人老了就是这样。

    作者回复: 👍

    2020-01-16
    2
    15
  • 山猫
    第一次听到DDD这个东西还是在一年前,仔细了解后发现,其实这个早在学习软件工程的时候就被提及。简单地说,就是针对某个领域,从功能或者组件的角度去进行对象的设计。 另外关于 35 岁的问题,我认为除了要保持学习能力外,还需要有系统架构能力和丰富的经验,同时还需要了解经济、历史、政治,锻炼自己的社交和口才。

    作者回复: 👍

    2020-01-08
    11
  • 个人从传统mvc转到领域驱动的主要动力是,领域驱动的代码模型中使用设计模式提高对需求的响应能力很方便,比如校验做成责任链,加个策略实现,模板。

    作者回复: 可以写一篇文章详细讲讲你的领域驱动设计实践吗?文章发到评论区一起学习下。

    2020-08-04
    2
  • 一只小菜鸟
    公司是不需要程序员的,公司只需要能创造价值的人。大龄程序员的优势是他不仅仅是一个程序员了,他更是在某一业务、某一领域内的领域专家,而且知道如何用技术去解决实际问题,创造价值。
    2020-01-11
    60
  • 搞怪者😘 😒 😏 👿
    老师可以提供一下领域模型的例子吗,光看这个有点不懂
    2020-01-06
    1
    19
  • escray
    算是领域驱动设计的入门篇吧,如果想要深入学习,估计还得去隔壁的专栏看看,另外更重要的是如何在项目中落地。 有一个疑惑,关于实体,在面向对象分析的时候,似乎也是强调要找到业务领域、找到实体,当然可能不像领域驱动设计这么有针对性。 大龄程序员有什么优势? 先说劣势,比年轻人更贵,但是对工作的投入程度可能不如年轻人,如果不持续学习的话,那么技术也可能落伍,综合起来就是性价比太低。 优势呢,可能比年轻人成熟稳定一些,一般情况下不敢删库跑路,毕竟还要养家糊口。如果单写 CRUD 估计写不过年轻小伙子,但是如果是复杂一点的业务逻辑,经验可能还是会有一些作用。 对于大龄程序员在业务领域的积累,我有一点怀疑。其实这个和学习新技术一样,如果你不去学习和思考,那么就不会有什么积累。 最后,作为一个不必面对“35岁问题”的大龄程序员(因为我已经 40+ 了),仍然希望自己能去做技术,可是“留给中国队的时间不多了”。
    2020-09-25
    1
    12
  • 左耳朵狮子
    大龄人的优势,会学习和学习方向的效率是没有经验的人无法比的。 (比如,有经验的用google search 较没经验的用google search,可能就是两种完全不同的工具)。或者通俗来讲,学习某一方面,你不知道你不知道什么。有经验的,打一枪可能就学会了。没经验的打10枪才学会。(有人可能说,年轻的是个快枪手,那35岁怎么定的界限?心老了,18岁就已经是81岁了。这里不杠,34.5岁就年轻了?36.2岁就年老了?)
    2020-05-30
    3
    5
  • ant
    这一章,真的是感受到了理解层面的难度,或许当我对某一领域有了完全充分的理解,并参与了类似的模型设计,才能更好的理解理论层面!
    2020-01-06
    2
    4
  • 而立斋
    最大的优势就是耐操
    2020-06-03
    2
收起评论
显示
设置
留言
19
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部