软件研发中的错误假设

之前有位朋友加入了我的 x-series 支持群，问我是否用到了 DDD 的思想，由此展开了一段关于软件设计与研发中存在的错误假设的有趣对话。原文记录在此，供大家围观：

刘杰 2021/5/16 9:54:58@hejiehui 前辈，请问这套框架中有没有用到 DDD 的思想。我想要解决复杂业务在迭代的过程中只有用到 DDD，整个系统才是好维护的。

hejiehui 2021/5/16 10:06:25ddd 我了解的不多。个人观点，ddd 是面向对象的另外一套说法。对一般人来说面向对象已经很难了，我工作这么长时间都很少很少看到高手。ddd 重新发明一套术语把这个概念搞得更加难以理解。我这套框架在设计的时候纯从面向对象出发的，和使用方约定了最小化的编程接口。你可以把这看做是框架自身的 ddd。至于业务自身的 ddd，则隐藏在接口实现后面

hejiehui 2021/5/16 10:12:27 顺便说一下维护复杂业务的思路不是 ddd。那只是刚开始做的第一阶段的事情。任何软件发布后，接下来的第一个新需求变更都可以看做是该软件进入维护阶段。维护阶段想要在迭代中提高可维护性真正要做的事情就是尽快根据变更的需求吧系统中不变的部分抽象出来，把变化的部分隔离开。通过这种办法把整个系统固定或者说假设的部分尽可能扩大，把变更部分尽可能缩小。只有需要真正理解和修改的地方最小化，才能保障系统维护阶段的可理解性与可维护性。除此以外，都是死路

刘杰 2021/5/16 10:13:31 我非常认可你这个观点，我对 DDD 比较感兴趣，也是因为我发现我所见到的所有系统都是用面向对象的技术开做面向数据的开发。其实 x-series 就已经是 DDD，对吧。

hejiehui 2021/5/16 10:14:42 我觉得可以这么认为。面向对象真正学好已经可以做一切事情了

hejiehui 2021/5/16 10:19:42 你可以回忆一下你接触过的系统。里面最复杂，最晦涩的一般都是处理步骤或流程，其次是对当前上下文做决策判断，比较少见但还是存在的就是对实体状态做操作。这就是 x-series 三个组件发挥作用的地方。应该还有其他的通用逻辑结构，但我目前所知就这些

hejiehui 2021/5/16 10:20:04 如果谁知道有类似的东西可以告诉我

耿小返加入本群。

刘杰 2021/5/16 10:30:24x-series 可能是独家，我也找了很久。之前我找过 COLA 框架，他们也提出过 状态机 这样的机制。COLA 主要是解决把代码归归类的问题，让代码更整洁好维护。面对复杂业务流程的问题，还是的靠自己分析解决。更没有一个可以直观的可维护机制。

hejiehui 2021/5/16 10:33:02 那种做法还在我说的第一阶段

hejiehui 2021/5/16 10:34:17ddd，面向对象，包括 cola 框架这些解决方案都有一个隐藏的前提，这个前提是制约这些方案是否成功的关键。不知道你有没有看出来

刘杰 2021/5/16 10:35:08 前提就是 我们对业务已经分析都非常透彻了。

hejiehui 2021/5/16 10:35:25 这个不是根本前提

hejiehui 2021/5/16 10:35:50 你想想怎么样才能对业务分析透彻

hejiehui 2021/5/16 10:38:01 给你点提示，不要盯着看业务自身看

刘杰 2021/5/16 10:38:52 这个问题 我之前思考过很久，一开始我以为是开发人员的事情，以为靠几个框架就能解决问题。后来我发现我太天真了，从领域到产品到架构师到开发人员，都必要要有很强的 业务抽象能力。这是一个团队的问题啊。

刘杰 2021/5/16 10:41:10 所以我后来才去思考 DDD 的问题，因为他提出了 统一语言 的设想。协调团队的一致性。但是我想想 这也太难了吧。

刘杰 2021/5/16 10:41:36 关是开发人员，对 DDD 的理解就已经很难了。

hejiehui 2021/5/16 10:41:45 算对的。这个前提就是你要用好这些方法得先学好，学好这些则需要对应的人有很有素质。而恰恰是需要很好的人员素质这一点是假设成立但现实中几乎完全不成立的。你看看是不是这样

hejiehui 2021/5/16 10:43:52 搞软件的提出方法论的都是大牛。理论都很完美，问题是这是大牛的做事方法。咋们普通人根本没能力掌握。承认这点很难

刘杰 2021/5/16 10:44:11 是的。就像你说的，能用好面向对象就已经没几人了。所以让团队中的大部分人 具体很强的 抽象能力 几乎是不现实的。

Mr. Liang 2021/5/16 10:46:58 是啊

hejiehui 2021/5/16 10:51:46 是的。那么面对包括自己在内的一群普通人如何把事情做好呢?硬着头皮学大牛当然是个办法。这是最笨的办法。聪明的办法就是找到套路，比如软件里面 90%工作就是一步步的处理，那么用 xunit 先按照一般人都能理解的方式把步骤画出来，再去填空，这基本上已经可以搞定所有系统了。碰到复杂逻辑就用决策树，用可视化的方法拉产品经理进来一起看，锅一起背。状态机也一样。这不是我给自己的广告，这就是现实中正确的做法

hejiehui 2021/5/16 10:57:22 这也是目前各种低代码无代码方案的思路。各种工具区别主要在下手点不同，面向领域有宽窄，层面有深浅。绝大部分在前台业务层，我这个工具在后台逻辑层。

刘杰 2021/5/16 10:57:40 是的，对于所有的业务系统来说，已经是非常理想化场景了。把文档都能统一进来了。我想 这就是  “活文档”

hejiehui 2021/5/16 10:58:52 对的。模型就是文档就是实际系统。没有代码生成或者其他转化步骤，因此就没有各阶段产出同步问题

hejiehui 2021/5/16 11:00:17 仅仅在提供实现的类里面研发人员才有必要提供文档。绝大多数情况下可视化模型本身就是自解释的文档