目录
如何实践 DDD 领域驱动设计: 第一篇 价值
前言
看了太多的 DDD 文章, 大多数作者都在想办法把 DDD 讲清楚。然而 DDD 本身是一种方法论,比较务虚。它的成果也是较难量化的东西,拿它去跟其他的方法论去对比,很难有说服性。
接下来我将分多篇文章探讨,如何实践 DDD,以发挥其价值。在这个过程中,我不会对概念进行过多的解释,因为概念不重要!过多的强调概念,在推进项目落地时,反而需要花费更多的时间去解释。我们不可能让每一个人都认同自己。但请相信:
真理往往掌握在少数人手中 —— 列宁
一、价值
讨论价值并不是务虚。这是我们去实践 DDD 的理由。没有傻子愿意去做对自己没有好处的事儿。
第一篇文章的重点是“洗脑”。打心底的认可与接受是实践的的前提。
为自己洗脑,看看 DDD 如何带给自己更好的未来;
为公司洗脑,看看 DDD 如何能为公司的可持续发展作出贡献;
作为 Leader,我们还需要为自下属洗脑,让他们也能认识到价值,与我们齐心协力。
-
对个人的价值 —— 持续成长
首先,我先抛出一个我们看过无数次的问题 —— 35岁以上的程序员都去哪了?
我听说过的,好的有:退休、创业、总监、架构师、技术经理、技术专家……, 一般点的有:回老家、转行……,比较悲伤的:故去。
你见过多少一直坚持在高级研发、资深研发的大龄程序员呢?有,并不多。他们面临了太多的压力与挑战。
重复搬砖、CURD,这些工作,年轻程序员也能做,他们没有家庭的负担、精力充沛、能够拼搏、接受公司的大饼,对未来有着美好的向往,有更大的成长空间!最关键的是便宜!!! 然而,当我们成为大龄程序员的时候,多年来的搬砖经验能为企业带来什么价值呢?
35岁,要么出色、要么出场!
如果要在这个行业可持续发展,我们必须出色!我们必须提升自己的价值!
程序员的价值
价值是价格的基础。程序员的高薪是因为程序员能创造巨大的价值。
35岁出场,本质上是我们无法创造与价格对等的价值。企业的收入受到两方面影响——开源、节流。我们创造的价值则在于“提效、降本”。也就是高效且低成本的开源节流!
优秀的程序员能够极大的降低企业的边际成本。100个人去做的工作,通过技术手段,10个人就能完成。我们创造的价值就是90人的工资。那我么拿10个人的工资就是应得的!企业才会愿意付出这么高的工资雇佣我们。
因此,我们要考虑的是如何持续提升自身的价值,而不是在35岁时创造25岁时一样的价值。下面我们站在 DDD 的视角探讨一下,DDD是如何帮助我们持续提升自身价值的。
DDD 对程序员的价值
- 提效
提效代表我可以用更少的时间完成任务,也可以用同样的时间做更多的事儿。争取到的时间,可以不加班,也可以提升绩效(技术提升、产出提升、质量提升),也可以学习自己感兴趣的知识。
有了这些节省出来的时间 除了默默无闻的搬砖,你还可以发光!
然而不幸的是,软件具有复杂度。复杂度必然会随着时间而增长。复杂度越高,研发效率越低。很多未经合理设计的代码,1年左右就变的不好维护。迭代周期增长、Bug增多。此时我们不得不对软件进行重构。 图中红线是采用 领域驱动设计 时的研发效率曲线。我们期望从中长期提高我们的研发效率。
- 长期积累设计经验
设计经验的积累能够帮助我们更快速更详细的完成软件设计分析工作,同时丰富的经验可以提高我们设计的成功率。设计的越多设计经验积累的越多——这是废话,但有意思的是,这句话很重要!因为他说明了,时间与经验是 正相关 且 经验与个人价值是 正相关, 所以 时间与个人价值是 正相关!综合我们对“程序员的价值”的讨论,我们得出一个结论:
DDD 的实践可以长期提升我们的个人价值,从而避免面临35岁的中年危机。
- 业务导向
领域驱动设计,需要我们足够的了解业务领域,我们需要站在业务的角度思考问题。了解业务可以让我们更有前瞻性,可以让我们做出更符合业务场景的系统,可以让我们的系统随业务的发展而持续演进。
业务导向,可以丰富我们的设计经验。良好的设计,可以降低复杂度,从而研发提效。
高端的职位,往往关注的是我们对业务的理解。解决了什么业务问题?因为公司的高管、总监关心的是公司业务的提升。不关心业务的程序员,晋升的道路世间难的。
DDD 锻炼我们的业务导向思维方式,会帮助我们向更高的地方前进。
- 掌握主动权 更开心的工作
当我们足够了解业务的时候,我们就是所在领域的专家。我们会发现业务上存在哪些问题,我们可以帮助业务做出改进,为业务赋能。——提效、降本
当我们帮助业务解决了更多的问题,就能建立了更多的信任。信任,让我们可以有更多的话语权,可以更平等的沟通。
当我们参与到业务里的时候,我们就不是工具人了,而是参与者,甚至是主导者。我们做自己想做的事情,当然能更开心的工作^_^
这真不是瞎说,后面我会找机会,拿一个具体案例聊一聊,业务架构师是如何沟通需求的。
-
对公司的价值 —— 也是对管理人员的价值
这部分内容,站在企业管理者视角来讨论 DDD 的价值。
领域驱动对公司的价值,非常的赤裸裸了,公司最关心的问题是盈利!
盈利 = 开源 + 节流
节流 = 降低成本
成本 = 人 x 时间
人力成本,随着社会发展,只会越来越高。如下图,是2010年~2020年北京市历年社会平均工资,互联网行业的从业人员的平均工资是远高于这个数据的。从更长周期来看,我们能发现,平均工资每5~7年就能翻一番。相信在不远的未来,终有一天会像美国一样——人力成本高昂,企业需要从劳动密集型转向技术密集型。提效降本对企业会越来越重要!
DDD 对企业的价值
- 提效降本
DDD 的 Silougen —— 软件复杂性的应对之道。其目标是提效降本,延长软件的生命周期。
提效,意味着时间消耗减少。时间消耗减少有两个好结果。
其一,时间消耗减少意味着投入的人力减少,投入的人力减少会降低雇佣成本、降低管理成本、降低公司运作风险。同时,能够解决市场上合格的研发资源短缺、招聘困难的问题。
其二,时间消耗减少意味着可以快速迭代,加速产出。产出加速我们可以更快速的支持业务的发展与试错,从而在行业竞争中占据更多的优势。这在中台战略的相关文章中也有说明。
PS. 一个可能不太恰当的例子——对手在手工制造弹药,而且在雇佣更多的工人制造弹药。此时,我们是否要雇佣更多的工人与其竞争?还是要改进生产工艺与设备,实现自动化生产呢?
降本,意味着资源消耗减少;
其一,我们可以支持长期的可持续发展,有更强的抗风险能力。
其二,我们更具竞争力,同样的效果只需要更小的开销。对手可能会进入 扩大开发、疲于应付、重构 的恶性循环。
其三,财报更好看…… 有啥好处大家都懂
提效降本,企业在抢夺市场中就能更加从容,比对手更有竞争力。有弹药才能够长期竞争。
- 知识沉淀
新员工加入团队最头疼的就是学习现在的业务知识、技术架构、业务逻辑等知识。最痛苦的莫过于不了解公司的业务关系结构。从我入职一些公司的体验来讲,真是让我痛不欲生。体验差到让我真的是入职一两周闪离(当然还有其他因素的存在)。
这些公司的新员工,从什么渠道获取业务知识呢?
1. 口口相传
2. 对公司产品的使用体验
3. 扒历史需求文档 🤮
4. 扒代码 🤮
在 DDD 里有“统一语言”的概念。“统一语言”不是一个“动宾短语”,而是一个“名词”。它指的是我们描述领域知识、进行沟通的标准语言。统一语言包括 自然语言、文本语言、图形语言 三种语言形式。显然,“口口相传”就是在使用“自然语言”传播领域知识。
自然语言的有点在于——快速、直接;缺点在于——只能主动传播、会遗漏失真、不能检索;显然,当关键员工流失时,知识的传递就会存在重大的隐患。我们不能仅依赖图形语言传播知识,我们还需要使用文本语言、图形语言对知识进行沉淀。
知识不能沉淀会影响新员工的融入效率,甚至会造成优秀人才的流失。
相反,图形语言沉淀的领域知识——能够快速、清晰的帮助新员工、跨团队写作的伙伴、不同角色的伙伴对领域知识有一个快速的理解。不仅能够达到提效的效果,还能确保知识传递的准确性,避免因为知识传递缺失造成的业务损失。
- 促进创新 —— 核心竞争力
创新是引领发展的第一动力。
这句话是 党的十八届五中全会通过的《中共中央关于制定国民经济和社会发展第十三个五年规划的建议》提出的。
创新能力也是企业竞争的核心竞争力。
DDD 之所以能促进创新,有以下原因:
原因一: DDD 的设计推动领域专家深入理解业务领域。不仅需要对公司本身的业务领域有足够的的了解,也需要对行业有足够的了解。只有对业务足够的了解,才能发现业务中的不足,提出问题、进行改造。对业务问题的分析和解决就是一种创新的过程。
原因二:我们对业务能力的抽象,往往会促使我们构建出耦合度低、复用程度高的平台系统。这些系统能够提高研发效率、降低研发成本。快速支持新的业务、降低业务失败的研发成本,帮助我们降低了创新失败的风险、降低了创新的难度。创新很难!高效低成本的试错是创新必要的条件。
- 延长技术软件的生命周期 —— 降本
上面的复杂度的示意图就是在说明复杂度的提高影响了软件的生命周期。当复杂度高到一定程度时,维护成本提高、迭代效率降低、问题出现概率增高。为了解决不可维护的问题,不得不重构系统。此时上一个版本的服务生命周期结束,重构需要投入大量的经历和人力。因此延长服务的生命周期,本质上就是降低成本,从而为企业带来更多的盈利空间。
领域驱动设计之所以可以提高软件的生命周期,其本质思维方式是在开发前对领域、业务模型进行分析设计。
其一:基于这个业务模型可以使业务、产品、研发、测试达到认知的统一,避免错误理解造成的项目回滚或将错就错。
其二:基于这个模型,可以理清领域间的关系与边界,每一个领域可以更好地解耦,领域间有更加明确地交互方案。从本质上降低的沟通成本、管理成功。而且,领域拆分的合理,可以有效地降低单个领域内的复杂度,从而延长软件的生命周期,提效降本。
其三:基于领域模型可以构建与模型一致的代码结构。代码结构与模型一致可以更方便的分析实现是否正确。更重要的一点是 领域模型不是一成不变的,业务稳定才能做领域驱动设计是误区!
业务是持续迭代演进的,业务模型跟业务的迭代一同迭代,代码与业务模型一致才可以跟业务往相同的方向迭代。这种跟业务一同课持续迭代的代码结构是软件生命周期的基本保障。
- 促进设计思考 做对的服务
目前互联网行业最常见的开发过程是什么?业务提出需求,产品整理成需求文档,研发按照需求文档定义前后端接口,设计数据库,定义好数据转换和流转过程,开发提测。
怎么论证设计是否正确?凭感觉吧~ 怎么知道结果是否正确?测试按照需求操作一遍吧~
这种没有从业务领域分析设计过得代码是不负责任的,只能实现一时的需求。需求迭代变更时,用不了多久就会发现代码是不可维护的。这正是我们上面说软件生命周期短的重要原因。
要求分析设计领域模型,强制研发去思考业务是什么样子的,才有可能提高设计效果,才更有可能做出正确的服务。虽然我们不能保证领域模型一定正确,这需要丰富的经验去支持。但我们可以降低错误的概率,做总比不做强。
- 促进员工个人提升
通过要求员工思考领域模型,不仅可以让我们的系统更加合理,也促进了员工对设计能力的积累。对员工个人能力的提升,可以回到上面个人价值部分。