本文书接上回《DDD是软件工程的第一性原理?》,关注公众号(老肖想当外语大佬)获取信息:
- 最新文章更新;
- DDD框架源码(.NET、Java双平台);
- 加群畅聊,建模分析、技术实现交流;
- 视频和直播在B站。
假DDD的特征
在开始之前,考虑到目前关于DDD的资料非常多且杂,我们需要具备分辨的能力,确保不被误导。看过本系列文章的朋友,对我们是如何看待DDD的会有一定的感受,这里我们列举一下我们认为的假DDD的特征,供大家参考:
- 堆砌抽象词汇,让人不明觉厉的
- 说DDD只有高级开发者才适合的
- 说DDD很难落地的
- 说只有复杂项目才适合的
- 说只能凭经验的
适合人群
首先我们认为“领域驱动设计是一种价值观”,那么理解并能够实践DDD的前提,认可这种价值观,既然如此,说明第一步的起点,是没有门槛的,只要你主观上认同即可,所以我们认为DDD适合软件工程工作相关的各个角色来学习和实践,包括但不限于:
- 期望从事软件领域的在校学生
- 各个层级的软件工程师
- 产品经理
首先软件工程师得懂DDD,这是毋庸置疑的,我隐约有一种感觉,真正的DDD就是软件工程的唯一正解,不少后端老司机一直苦于随着时间的推移,系统代码快速腐化的问题,而DDD正是对抗这种腐化的底层逻辑,是软件工程的第一性原理。
对于学生群体,我接触的案例证明,对于软件领域的新人,反倒更容易理解和接受DDD,这是因为目前主流的软件设计指导,很多都指向了与DDD相反的方向,新人因为没有被这些信息所误导,没了先入为主的思维枷锁,很自然地容易接受更有收益的软件设计思想。
软件工程师最喜欢的产品经理,大概率是懂一些技术的产品经理,而如果对DDD的概念有所理解的产品经理,我相信在需求分析、产品设计、模型设计方面能够与工程师更容易相互理解并建立共识,大家一定还记得之前文章所说的“拟人化建模沟通法”,在这里更是能发挥巨大的作用,使得“需求-模型”的一致性得到更好的保障。
学习路径
下图展示了一个学习的循环迭代,我认为可行几点如下:
- 学概念,通过系列文章、视频,构建基本概念认知
- 学实践,使用DDD框架做代码练习
- 做验证,一个教练指导并不断地实战体验,迭代认知和行为
学概念
我们认为DDD的概念是具体的,是容易理解和实践的,如果你有通读本系列的前文,那么一定会有所感受,《老肖的领域驱动设计之路》,其中关键的概念观点包含但不限于:
- 领域驱动设计是一种价值观
- DDD原则
- 边界明确是最重要的事
- 一致性比正确性更重要
- DDD是软件工程的第一性原理
- 系统的复杂度来自元素的数量和元素之间的关系
- 复杂度守恒定律
- 拟人化建模沟通法
- 不要复用
- 万能模型之“命令-事件”
- 如果写代码别扭,大概率是建模出了问题
学实践
学实践,就是不断地建模设计、代码实现,目前我们已经为Java、.NET生态分别提供了DDD战术框架,基于战术框架,并配套了工程模板,期望能够帮助你的团队在没有技术负担的状态下体验DDD带来的优势和收益,从而增强团队的DDD认知:
Java:https://github.com/netcorepal/cap4j
.NET: https://github.com/netcorepal/netcorepal-cloud-framework
关于教练
首先教练不是必须的,但一个好的教练,可以让你大大加速对DDD的认知和应用,教练的核心作用就是:
- 引导认知理解
- 教授实践方法
- 验证学习成果
那么对于一个好教练,我认为最关键的就是:能够判断决策(需求分析、建模设计、代码实现)是否符合DDD价值观。要做到这点,那么一个好教练大概率满足以下特征:
- 对DDD的理解准确
- 有实践的成功经验
哪里找一个好教练呢?(广告时间)在你眼前就有这么一位,关注我,我在直播间就是扮演教练的角色,欢迎互动交流。
视频与直播:
https://space.bilibili.com/6733407
如何判断成果
学习过程中,很重要的就是成果的正向反馈,关于DDD的学习,以我的经验来看,虽然无法给出明确的可量化的指标,但下面几点可以帮助你从主观上判断是否有进展:
- 对需求和系统有掌控感了
- 需求-模型-代码越来越一致了
- 写代码感觉丝滑了
- 代码BUG率有显著的改善
最后
欢迎交流实践经验,持续提高开发者的幸福感。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。