工序的执行和工序的设计可是不同的，不能混淆这两个意义。不是说有了这些框架，拿着OO的Java工人就变成OO派了，真正的OO是要和业务员，和领域专家一起讨论才会知道的，当设计一个良好模型满足他们的需求变更时，工人就变成了设计师，他设计了这个工序，改良了工序的执行（能迅速响应各种需求变更）。没有应用场景也就没有模式什么的了，闭门造车做出来的系统是不能满足应用的，因为单靠自己是无法确认这个领域究竟是什么样的，只会造出来一个看着挺好，但实际用不上的软件。

可能一个Intel工厂里的设计者正在聚精会神地研究24核CPU是什么样的，因为他学的就是计算机电气电工，而另一些人正在讨论为什么这个销售模型即将崩溃了，因为他们学的就是开发业务软件。觉得自己在哪个位置是只有自己才知道的事情。

工序： 1.分析建模 2.模型设计细化 (这两个工序需要Evans DDD) 3.架构(选择或设计) 3. 编码实现 4.测试调试 5.部署运行。

工人就是从第3个阶段介入。前面需要架构师和建模业务专家，也可以聘请专业咨询公司介入咨询。

整个工序前面3个阶段价值最高，也是70%贡献，但是现实中，这部分重视不够，这样，第4阶段就依赖测试工程师来补救，所以，为什么市场上测试工程师很热，这是由于错误的软件工程思路导致。

<工序： 1.分析建模 2.模型设计细化 (这两个工序需要Evans DDD) 3.架构(选择或设计) 4. 编码实现 5.测试调试 6.部署运行。>

用目标（做什么），方法(怎么做)，行动来做如下分析行吗?

（分析建模，模型细化）是强调分析目标吗?要管理什么数据，要有什么功能，是了解做什么。

（架构，编码实现，测试调试）是强调分析方法吗？怎么管理数据，怎么管理功能，是去想怎么去做的问题。

（部署运行）是怎么去执行。

如果是这样子分析可行的话，我觉得不是对前3不够重视，而是这没方面的杰出的人才，无法做出响应变化的需求分析。前面的工作没做好，再加上分工不明确，所以后面才要去补救，增加4,5的工作量，过度的要求第3,4步的能力还要去分析什么是变化的。

现在基本都是敏捷工程方法。