以下是一个好的架构应该解决的问题列表。该列表并不是要成为架构的综合指南，而是一种实用的方式来评估程序员获得的内容是否足够有营养。

使用此清单作为起点。与需求清单 一样，如果你正在处理一个非正式项目，你会发现一些甚至不需要考虑的项目。如果你正在从事一个较大的项目，那么大多数项目都会很有用。

#具体的架构主题

  • [ ] 程序的整体组织是否清晰，包括良好的架构概述和理由？
  • [ ] 主要构建模块是否明确定义，包括其职责范围以及与其他构建模块的接口？
  • [ ] 需求列表中的需求，是否都能合理的被架构中的模块覆盖？即不会有太多的模块需要因为一个需求而改动的情况，也不会有所有需求集中在一个模块内的情况出现。
  • [ ] 架构中最关键的类是否被合理的描述，且证明了其合理性？
  • [ ] 数据的设计是否得到了描述，并证明了其合理性？
  • [ ] 数据库之间的组织关系是否有被定义？
  • [ ] 是否所有关键的业务规则都有被定义，且说明了它们对系统的影响？
  • [ ] 是否描述了针对 UI 设计的策略？
  • [ ] UI 部分是否模块化，以便它不会影响程序的其他部分？
  • [ ] 是否描述了处理 IO 的策略，并证明了其合理性？
  • [ ] 是否对线程，数据库访问，句柄，网络带宽等稀缺资源描述了使用估计和资源管理策略，并证明了其合理性？
  • [ ] 架构是否描述了对安全性的要求？
  • [ ] 架构是否为每个类，每个子系统和每个功能都设置了空间和时间的预算？
  • [ ] 架构是否描述了如何实现可拓展性？
  • [ ] 架构是否解决了互操作性问题（其他软件/硬件共享的资源）？
  • [ ] 架构是否描述了本地化策略
  • [ ] 架构是否提供了一致的错误处理策略？
  • [ ] 架构是否定义了容错方法？
  • [ ] 系统中所有部分技术可行性是否已经确认？
  • [ ] 架构中是否有足够的饱和设计？
  • [ ] 架构是否有 购买/构建 的决策说明？
  • [ ] 架构是否有描述如何重用代码以符合其他的架构目标
  • [ ] 当前架构是否能够适应可能的变化

#通用架构质量

  • [ ] 架构是否考虑了所有的需求？
  • [ ] 架构中是否存在过度或不足的设计，是否有明确描述这些区域的期望？
  • [ ] 整个架构在概念上是否一致？
  • [ ] 顶层设计是否可以独立于硬件和语言？
  • [ ] 是否描述了架构中所有重大决策的动机？
  • [ ] 作为要实现该系统的程序员，你对架构是否满意？