头图

本文书接上回《DDD是软件工程的第一性原理?》,关注公众号(老肖想当外语大佬)获取信息:

  1. 最新文章更新;
  2. DDD框架源码(.NET、Java双平台);
  3. 加群畅聊,建模分析、技术实现交流;
  4. 视频和直播在B站。

假DDD的特征

在开始之前,考虑到目前关于DDD的资料非常多且杂,我们需要具备分辨的能力,确保不被误导。看过本系列文章的朋友,对我们是如何看待DDD的会有一定的感受,这里我们列举一下我们认为的假DDD的特征,供大家参考:

  1. 堆砌抽象词汇,让人不明觉厉的
  2. 说DDD只有高级开发者才适合的
  3. 说DDD很难落地的
  4. 说只有复杂项目才适合的
  5. 说只能凭经验的

适合人群

首先我们认为“领域驱动设计是一种价值观”,那么理解并能够实践DDD的前提,认可这种价值观,既然如此,说明第一步的起点,是没有门槛的,只要你主观上认同即可,所以我们认为DDD适合软件工程工作相关的各个角色来学习和实践,包括但不限于:

  1. 期望从事软件领域的在校学生
  2. 各个层级的软件工程师
  3. 产品经理

首先软件工程师得懂DDD,这是毋庸置疑的,我隐约有一种感觉,真正的DDD就是软件工程的唯一正解,不少后端老司机一直苦于随着时间的推移,系统代码快速腐化的问题,而DDD正是对抗这种腐化的底层逻辑,是软件工程的第一性原理。

对于学生群体,我接触的案例证明,对于软件领域的新人,反倒更容易理解和接受DDD,这是因为目前主流的软件设计指导,很多都指向了与DDD相反的方向,新人因为没有被这些信息所误导,没了先入为主的思维枷锁,很自然地容易接受更有收益的软件设计思想。

软件工程师最喜欢的产品经理,大概率是懂一些技术的产品经理,而如果对DDD的概念有所理解的产品经理,我相信在需求分析、产品设计、模型设计方面能够与工程师更容易相互理解并建立共识,大家一定还记得之前文章所说的“拟人化建模沟通法”,在这里更是能发挥巨大的作用,使得“需求-模型”的一致性得到更好的保障。

学习路径

下图展示了一个学习的循环迭代,我认为可行几点如下:

  1. 学概念,通过系列文章、视频,构建基本概念认知
  2. 学实践,使用DDD框架做代码练习
  3. 做验证,一个教练指导并不断地实战体验,迭代认知和行为

图片

学概念

我们认为DDD的概念是具体的,是容易理解和实践的,如果你有通读本系列的前文,那么一定会有所感受,《老肖的领域驱动设计之路》,其中关键的概念观点包含但不限于:

  • 领域驱动设计是一种价值观
  • DDD原则
  • 边界明确是最重要的事
  • 一致性比正确性更重要
  • DDD是软件工程的第一性原理
  • 系统的复杂度来自元素的数量和元素之间的关系
  • 复杂度守恒定律
  • 拟人化建模沟通法
  • 不要复用
  • 万能模型之“命令-事件”
  • 如果写代码别扭,大概率是建模出了问题

学实践

学实践,就是不断地建模设计、代码实现,目前我们已经为Java、.NET生态分别提供了DDD战术框架,基于战术框架,并配套了工程模板,期望能够帮助你的团队在没有技术负担的状态下体验DDD带来的优势和收益,从而增强团队的DDD认知:

Java:https://github.com/netcorepal/cap4j

图片

.NET: https://github.com/netcorepal/netcorepal-cloud-framework

图片

关于教练

首先教练不是必须的,但一个好的教练,可以让你大大加速对DDD的认知和应用,教练的核心作用就是:

  1. 引导认知理解
  2. 教授实践方法
  3. 验证学习成果

那么对于一个好教练,我认为最关键的就是:能够判断决策(需求分析、建模设计、代码实现)是否符合DDD价值观。要做到这点,那么一个好教练大概率满足以下特征:

  1. 对DDD的理解准确
  2. 有实践的成功经验

哪里找一个好教练呢?(广告时间)在你眼前就有这么一位,关注我,我在直播间就是扮演教练的角色,欢迎互动交流。

视频与直播:

https://space.bilibili.com/6733407

如何判断成果

学习过程中,很重要的就是成果的正向反馈,关于DDD的学习,以我的经验来看,虽然无法给出明确的可量化的指标,但下面几点可以帮助你从主观上判断是否有进展:

  1. 对需求和系统有掌控感了
  2. 需求-模型-代码越来越一致了
  3. 写代码感觉丝滑了
  4. 代码BUG率有显著的改善

最后

欢迎交流实践经验,持续提高开发者的幸福感。


老肖想当外语大佬
7 声望2 粉丝

FireUG社区组织者之一、微软MVP,B站同号