- 在实际应用中，其实不存在一个本质上完全好的架构或者本质上完全糟糕的架构，各种架构总能够或多或少的满足某些系统的要求。
- 可能对于一些企业或者项目来说，这样的架构是很好的，但对于另一个项目来说，可能就完全不适用，比如对一次使用的临时系统来说，使用具有很好的可修改性的架构没有任何意义。
- 根据不同系统的不同目标，我们可以对架构进行评估，这是我们关心架构的原因之一。
- 这就需要在设计架构的过程中遵循某些实践准则，当然忽视某一条准则，并不意味着整个架构都是完全失败的。至少可以把这些准则作为你评判架构标准，更好的对你的架构进行分析。
- 我们把经验分为两类，关于过程的建议和关于产品(或结构)的建议
Process recommendations
- 通常只是选择用一个架构师或者由一个明确指定的技术总监领导的一个小的架构师团队来实现某个架构，这样保证架构概念的完整性和技术的连贯性，同时架构师和开发团队之间应该有紧密的联系，确保架构不会出现某些不可能实现的象牙塔设计。
- 架构师在设计过程中应该有一份划分了质量属性优先级的质量属性列表，这就意味着折衷和权衡。(功能性就没有质量属性那么重要)
- 架构应该使用视图的方式记录下来，这些视图应该将项目生命周期中重要干系人的关注点都记录下来也就是说，一开始只是有少量的文档，后面慢慢进行详细描述，这些关注点通常涉及到系统的创建，分析和维护，还有为新的干系人进行系统的介绍。
- 在系统开发初期，应该时常测试和评估架构，检测它是否在围绕系统的重要质量属性实现，这样可以保证所有所有对架构的改变都不会违背设计的初衷。
- 架构的设计实现应该是一个迭代增量的过程，而不是在一开始就集成所有的功能点，系统的骨架图可以很好的解决这个问题，系统骨架图就是一开始只完善了模块和模块之间的联系，而不是过多的设计功能，在之后的系统开发过程中，以这个骨架图作为基础，逐步增加功能进行有必要的完善。
Product Recommendations
- 架构最终应该是由不同的模块组成，这些模块隐藏内部的功能实现，只对外提供接口，这样每一个模块内部的改变不会影响所有使用该模块接口的模块，这也就是封装。
- 除非系统的需求是史无前例的，要不系统的质量属性应该遵循那些已经存在的经典的架构模式和策略来定义。
- 架构最终不应该依赖于某个开发工具或者产品的某个版本实现，如果依赖是必须的，那么该架构至少应该保证在所依赖的产品的版本变更后，能够方便经济的适应。
- 产生数据的模块应该和使用数据的模块分开，这样可以提高可修改性，因为改变只是被限制在产生数据或者是消费数据阶段，有点像产生数据和消费数据对外只是提供自己的接口，对于它们内部是怎么产生和消费数据的是隐藏的。当要增加一个数据的时候，两个阶段可以同时进行改变，而不是需要系统逐步的进行升级。
- 模块和组件之间一对一的映射是不可能发生的，在支持并发的系统中，可能就有很多实现同一个模块的组件实例并行执行。
- 每一个进程的编写都要考虑到与特定处理器之间的关系，这样方便对分配进行变更。
- 架构应该采用少量的，简单的交互模式，也就是说，系统的功能应保持一致，这样可以提高系统的可理解性，可修改性，可靠性，并减少开发时间。
- 对于可能发生的资源争夺，架构中应该包括一个对资源的明确分配部分，即对一些使用到的资源进行合理有效的分配。比如，如果对网络的利用是我们关心的一部分，那么架构师应该具体对每一个开发团队进行限制，把网络拥塞降到最低；如果性能是我们关心的部分，那么架构师就应该对主要线程的时间开销做一些限制。
