《软件方法》第1章2023版连载（03）建模工作流

DDD领域驱动设计批评文集

做强化自测题获得“软件方法建模师”称号

《软件方法》各章合集

1.2 建模工作流

1.2.1 建模工作流ABCD

如何能做好需求和设计，达到“低成本制造好卖的系统”的目标？并非喊喊口号就可以，需要静下心来学习和实践一些必要的建模技能。

软件开发是增量、迭代进行的，每一个迭代周期都需要依次思考这么几个事情：

A-业务建模（business modeling）——定位需要改进的目标组织以及该组织接下来最需要改进的问题。

B-需求（requirements）——描述为了改进组织的问题，所引入的信息系统必须具有的整体表现。

C-分析（analysis）——提炼为了满足功能需求，所引入的信息系统需要封装的核心域机制。

D-设计（design）——考虑质量需求和设计约束，将核心域机制映射到选定非核心域上实现。

本书将以上ABCD称为软件开发的4个建模工作流。

如果采用本书的方法学以及UML表示法，其ABCD大致如图1-5。读者先看一眼即可，后文再详细解说图中内容。

图1-5 四个建模工作流（本书方法学+UML）

软件江湖中各种花里胡哨的用语，不管是真创新还是伪创新，基本上都可以用上面的ABCD来归纳，例如：

产品经理、需求工程师、需求分析师：A+B+部分C。

业务架构师：可能是A（此时“业务”的含义是“组织”），也可能是C（此时“业务”的含义是“核心域”）。

系统架构师：C+D。常有团队说要改进系统架构，其实他想改进的是B-需求。

领域驱动设计：C+D。也有团队声称要学习“领域驱动设计”，其实想解决的却是A-业务建模。

中台：C+D

微服务：C+D

设计模式：C+D

……

欢迎读者随时补充更新。

1.2.2 关于用词

“工作流（workflow）”沿用自RUP（Rational Unified Process）的早期版本，后来的RUP版本改为“科目（discipline）”。

在我看来，“工作流”和“科目”这两个词都不算太好，但目前没有更合适的选择，暂时先用“工作流”。

4个工作流的名称“业务建模”、“需求”、“分析”、“设计”沿用了以往各个方法学的用语，这些用语也不严谨。

例如，“业务建模”末尾有一个“建模”，其他3个却没有，难道其他3个不是建模？如果把其他3个也加上尾巴“建模”，就变成批量刷废话了；如果把“业务建模”的“建模”去掉剩下“业务”，意思已经不对。

甚至“业务”二字都是模糊用语，这个后文再详述。

更贴切的名称可能是：A-组织价值、B-系统责任、C-核心域逻辑、D-实现，但再三权衡，还是沿用之前的用语。

如果读者真正理解了ABCD的内容，叫什么问题都不大，改成A-阿猫、B-阿狗、C-阿鸡、D-阿鸭也无所谓。

1.2.3 逃不掉的思考

在迭代周期中，如果要追求好的结果，按A→B→C→D的顺序来进行推理是必须的，而且各个开发团队一直都在这样做。我们来看几个场景：

开发团队甲，所有成员都认真学习《软件方法》和认真做题，引进了UML和建模工具EA，并按照书中的改进指南改进，最终得到很不错的结果。开发团队甲的A→B→C→D很容易看出来。

开发团队乙，没听说过《软件方法》，也不用UML和EA，用的是技术总监自己归纳的一套“软件工程方法学”和符号，也还算行之有效。开发团队乙的A→B→C→D也容易看出来，但形式上和开发团队甲不同。

开发团队丙，快乐拥抱挂着“敏捷”或“领域驱动设计”名头的伪创新。这些伪创新投资少，见效快，门槛低，产量大，仪式感十足。开发团队轻松愉快、热热闹闹地讨论和糊墙。这里面有A→B→C→D吗？也许有一点，但很少，这些热闹只是装模作样。真正的A→B→C→D推理，可能是在编码的时候在大脑里朦朦胧胧进行的，推理的质量可想而知。

开发团队丁，觉得既然ABC我都不会，我也不想装模作样，就一步到D，直接编码。这种情况下，还有A→B→C→D吗？有的，和开发团队丙差不多，A→B→C→D推理，是在编码的时候在大脑里朦朦胧胧进行的，同样，推理的质量可想而知。幸好，省去了伪创新装模作样的成本。

开发团队戊的故事（纯杜撰，勿对号入座）看起来有点不一样。他们所在的公司赶上了风口，成了某个领域（例如预制菜）的互联网巨头。在开发和维护预制菜相关的项目时，开发团队戊觉得现在的前端框架Vue、React等还差点意思，于是搞了个内部项目，自研前端框架“闪电五连鞭”。过了几年，也许是风潮过了，也许是历史使命已经完成，预制菜市场冷却，反倒是“闪电五连鞭”框架受到全世界开发人员热捧，成为公司的生存支柱。这里面有A→B→C→D吗？看起来像是颠倒了？ 

再看一个特别的，程序员张三自己做一个东西给自己用。张三只会用编码工具，也没学过UML或类似的知识，这里面还有A→B→C→D的推理吗？

最后这两个，答案也是肯定的，并没有什么特别，具体留到后文详述。

总之，每一个软件项目，只要不是故意摆烂，开发团队都会有A→B→C→D的推理过程——也许无意识、隐式地做，也许有意识、显式地做；也许推理过程严谨合理，也许推理过程漏洞百出；也许分成很多人来做，也许一个人做；推理产物的形式也许是UML模型，也许是其他……

就像一道复杂的数学填空题，答案是97/2023，如果考生能填对这个正确答案，他必然在考试过程中的某个时间点做了正确的推理。只要不是故意摆烂，即使是学渣，也会尝试着去推理。只不过相对于学霸的一击必中，学渣可能要反反复复“敏捷探索”多次才答对，甚至直到考试结束还没答对。

本书希望教给读者一种严谨和高效的推理方法，当然，要掌握它没那么容易。