架构师吃掉需求，设计师吃掉架构，程序员消化设计。
就如同你做这个项目的时间越长，对这个项目的理解也就越深入一样，客户参与项目的时间越长，他们对项目的理解也就越深入。开发过程能帮助客户更好的地理解需求，这是需求变更的主要来源。
如果你的需求不够好，那就停止工作，退回去，先把它做好，再继续前进。
确保每个人都知道需求变更的代价，
建立一套变更控件程序，
使用能适应变更的开发方法，
放弃这个项目，
注意项目的商业案例－－要求给出商业理由，考虑需求的“增加的商业价值”
架构中，应该能发现对那些曾经考虑过的最终组织结构的替代方案的记叙，找到之所以选用最终的组织结构，而不用其它的替代方案的理由
“维护‘设计的缘由’”至少与“维护设计本身”一样重要。
对那些构成系统计80％的行为的20％的类进行详细说明
数据通常只应该由一个子系统或一个类直接访问
如果架构依赖于特定的业务规则，那么它就应该详细描述这些规则，并描述这些规则对系统的影响
架构的典型组成部分：
程序组织
主要的类
数据设计
业务规则
用户界面设计
资源管理
安全性
性能（定义各种资源之间的优先顺序）
可伸缩性
互用性
国际化、本地化
输入输出
错误处理
容错性
架构的可行性
过度工程
关于“买”还是“造”的决策
关于复用的决策
变更策略
架构的总体质量，维持其概念的完整性