一、找到够用的设计
架构设计的目标不是理性的寻找最佳设计，而是找到一个够用的的设计。
1）将解决方案看成实验：把每个可能的解决方案看成是待验证的实验，验证的速度和效率越高，找到合适的组合结构的时间就越短，利益相关方就能越快收益。
2）设法降低风险：架构是软件系统的技术，架构师必须时刻考虑哪些地方可能出错，并据此开展设计，根据风险决定接下来设计什么。
3）努力简化问题：将复杂问题分解为若干加单问题，会更容易解决。比如：减少利益相关方的数量可以减少冲突的观点；增加或较少约束条件、关注问题的子集，也可降低复杂度；识别常规问题，利用现成的解决方案解决。
4）快速迭代学习：学习越快，探索得越多，对解决方案就越有信心。如果有可能失败，越早知道越好。设计周期太长，则需要思考下目标是否过于宏伟抽象。
5）考虑问题和解决方案：问题的边界是由可能的解法勾勒的。为了理解问题，必须探索各种解决方案，而为了探索解决方案，又必须加深对问题的理解。软件架构设计需要同时考虑问题及其解决方案。
二、适当时间设计架构
前期如果不设计架构，开发出来的系统很可能不符合要求，同时，设计架构也能降低未来返工的风险；如果花大量时间设计架构，则会耽误开发，延误交付。因此，每个软件系统都有一个设计的最佳平衡点 —— 在开发之前用最适当的时间设计架构。
1）软件系统越大，前期做架构设计的收益越大：千万行代码的大型软件系统，将37%的时间花在架构设计上是一个明智的选择。
2）软件系统越小，前期做架构设计的收益越小：一万行代码的小型软件系统，架构设计时间不应超过5%。
3）前期架构设计做得不够，要对后期返工做好心理准备：小型软件系统前期不做过多架构设计可以缩短总工期，但是返工还是不可避免。如果前期架构设计做的不够，系统越大，后期返工的概率越高。
4）前期架构设计的投入越多，后期返工就越少：前期架构规划和设计有助于减少错误。如果重视项目的质量和可控性，而不在乎效率，可以多花点时间做前期架构规划。
三、用风险做导向
软件开发总是有风险的。写下系统的所有风险，对他们排序，列出优先级。把风险最高，最麻烦的排在前面，然后选择合适的思维模式降低风险。
（1）确定条件和后果
描述风险需要两个部分：条件和后果。条件是当前的实际情况，后果是由条件引发的、将来可能出现的不良状况。如：条件：供应商欠款未付，当前开发依赖的SDK拿不到，而公司付款需要至少3周 ——> 后果：软件开发时间顺延3周，总工期延长3周。
（2）借助风险选择思维模式
软件架构设计是一项降低风险的活动。风险帮助我们决定设计内容，思维模式帮助我们制定降低风险的策略。通过条件、影响、概率和事件窗口等因素来确定必须降低的风险的可以解决部分，需要选择合适的思维模式。
四、制定设计计划
设计计划表明了团队的总体策略。设计计划的内容需要包含以下几个方面：
（1）结束设计的条件：没有标准答案，很大程度上取决于团队、利益相关方、项目背景的实际情况。基于实际情况，来确定：是开始写代码前做尽量少的前期设计，还是尽可能完整地做好架构规划？各个部分的设计独立开展，还是某些部分需要一起开始？等等。
（2）必要的设计成果：在设计开始前，让大家明确如何记录架构设计。画在白板上拍照，还是用传统的文档记录？团队是否有现成的设计文档模板？设计成果（用例图、类图、UML模型图、设计文档等）应该存储在哪里？
（3）时间节点：给出关键设计工作的时间节点，如：需求审查、设计审查、设计评估等的时间节点。此外，还要给出利益相关方会面的时间节点，如：开发即将开始；初期要完成的工作范围等。
（4）重大风险：使用风险驱动的设计方法，应将重大风险也放到设计计划里。在软件系统的整个生命周期中（尤其前期的架构设计阶段），应该不断回顾风险列表。
（5）概念架构设计：可以先从可行的解决方案里选择一个，思考解决方案可以更好地帮助我们定义问题。概念架构不需要很复杂，可以画一张草图，只要能表达初步的设计想法就行。
