我说，钱多就设计的详细，钱少就设计的粗略。
他说，也许我们可以稳定到某一个程度，不论项目大小，钱多少。
我想，大家都体验到了UML为设计带来的许多好处，比如交流便捷，规范开发，还有就是强迫思考，强迫我们考虑“谁是谁”和“谁做什么”。
如何使用UML，Martin Fowler在《UML Distilled Third Edition》中做了很精辟的总结，我理理自己的思路，以飨大家。
在设计精细程度上，一般有三种用法：草图，蓝图和程序。
将UML视为草图，着重于沟通交流，在纸上或者白板上与一群人讨论，并不一定拘泥于UML的格式。我们不会讨论所有要写的程序，着眼点只在系统的部分或者某个层面。我们可以在几个小时的开发工作前，用10分钟交流下设计；或者用1天的时间，整理整理接下来为期两周的迭代。
这样的设计可能是非正式的，我们可以把白板上的照下来，把纸上的扫描下来，再加进设计文档。使用草图，也往往意味着我们会讨论一些可能的替代性做法。所以，Martin说草图的本质是“选择性”。
我觉着在YXXXX项目中，用的是这样的方式。我要求大家把接口定义出来，把主要的时序画出来，不论是在纸上还是在Visio上，已经画好还是现场画。我关心的接口有两部分，Java程序接口，主要是业务层接口，需要知道业务层暴露出哪些方法供别人调用；还有前后的数据接口，即DTO，我需要知道业务层的方法需要什么数据，会返回什么数据。我关心开发人员是否理解了调用顺序，以及开发人员的工作分配，即谁做哪个类哪个方法。
将UML视为蓝图，更倾向于“完整性”。我们关注于系统的整体结构，框架层次，必须完成大的设计决策。如系统是由哪些子系统/模块构成的，其间的联系是什么，层次如何分布，怎样限定层与层的通信，关键类的识别和关键方法的分配等等。
这时我们需要借助工具来完成，并遵循一些标准，比如命名方式，注释规则，画图约束等等。这样的设计一般比较正式，也可能是大多数项目所使用的。接下来，可能会继续细化，增加类的契约，方法的契约等等；也可能直接用来开发，更进一步的设计会在写代码前完成。
在TXX项目中，我们便用的是这种方式。我们识别定义了主要的类方法，但并未描述业务规则和异常，并未满足80/20法则（80%的方法和20%的类），对类和方法的描述也不是十分充分。而在实际开发过程中，蓝图更多的起指导作用，约束力比较小。
蓝图与草图的主要区别在于：草图强调信息通讯，而蓝图强调无所不包；草图具有探索性质，而蓝图是定稿。
如果在蓝图的基础上继续设计，那么写代码的工作也就将越“无趣”；甚至，如果工具支持的话，我们可以在UML中完成代码。MDA（模型驱动架构）就是基于这样的思路。将UML视为程序语言，就需要可以把设计人员画的图直接生成为代码，将写的说明性文字生成为注释。
目前这种方式我只是听说过，还从没有见过。
对于持有第一种视角的人来说，UML中最重要的是图；而对于后两种观点，UML最重要的是本质（分析方法、设计方法）。
而对于概念（概念是OO的核心）理解来说，也会有两种观点：软件观点（software perspective）和概念观点（conceptual perspective）。
持有软件观点的人的设计，任何UML元素（包、类、关系等等）都可以对应到软件的实体中；而持有概念观点的人，UML元素则对应到业务领域中的概念。
从程序员成长的设计师可能更容易具有软件观点；而概念观点更容易为业务领域专家所有。
回到我们的问题上，需要将设计做到什么程度。程度必然与衡量有关，而衡量就必须有标准。通过项目的积累，我们会逐步完善这个衡量标准。
排除设计观点的差异，忽略成本因素，与设计相关最直接的因素是：时间，作者（设计人员）和读者（开发人员）。
毋庸置疑，时间决定了设计的程度。不同的项目有不同的时间限制，而资源也是有限的，或许我们可以根据不同的项目类型，制定不同的设计标准。
设计人员的能力决定了设计的质量，也许会因经验不足，导致开发阶段风险与成本上升。提高设计能力是我们持久的目标。
不同的开发人员，对设计的要求应该是不同的。如果是成员之间比较熟悉的团队，草图的方式是最便捷和有效的；如果开发人员水平参差不齐，使用蓝图不失为一个好办法；而开发人员仅仅是传说中的“蓝领”，那么我们不得不将设计视为程序。
除此，还有很多重要的因素，如软件开发的生命周期，需求稳定程度等等。
最后的结论是，设计可能无法稳定到一个程度，也许WQX的意思是我们可以稳定到某一种质量。
欢迎讨论！