应用程序体系结构清单中应包含哪些内容？
我试图想出一个清单或一组问题/标准来评估和评估提出的或新兴的体系结构（执行体系结构评估）。 在尝试计划，评估或评估一个架构时，您提出的最重要的问题是什么？
我知道这是一个很大的话题，所以我想把它限制在一个端到端的系统中，而不是整个组织的体系结构。
Code Complete提供了一个体面的起点：
build筑
- 程序的总体组织是否清晰，包括良好的架构概述和合理性？
- 模块是否定义良好，包括其function和与其他模块的接口？
- 这些要求中列出的所有function是否明智地涵盖了，既不是太多也不是太less的模块？
- 这个架构是否适合可能的变化？
- 是否需要购买与构build决策？
- 架构是否描述了如何重用代码以符合其他架构目标？
- 所有的主要数据结构都隐藏在访问例程之后吗？
- 数据库的组织和内容是否合理？
- 是否所有关键algorithm都被描述和certificate了？
- 所有主要的对象都被描述和说明了吗？
- 是否描述了处理用户input的策略？
- 是处理I / O描述和合理化的策略？
- 用户界面的关键方面是什么？
- 用户界面是否被模块化，以便其中的更改不会影响程序的其余部分？
- 内存使用估计和内存pipe理战略描述和合理化？
- 架构是否为每个模块设置了空间和速度预算？
- 处理string是一种策略吗？是string存储估计吗？
- 是否提供了一致的error handling策略？
- 是否将错误消息作为一个集合进行pipe理以呈现干净的用户界面？
- 是否指定了一个健壮的级别？
- 是否有任何部分超过或低于架构？ 这方面的期望是否明确？
- 主要的系统目标是否明确说明？
- 整个build筑在概念上是否一起挂？
- 顶层devise是否独立于将用于实现它的机器和语言？
- 是否提供了所有重大决策的动机？
- 作为一名程序员，你是否会执行这个系统，对架构感到满意？
我正在用实例来寻找实践知识，例如，您创build的架构中最痛苦的是什么？
基于我的研究，这里是一些架构审查清单，我发现这个问题多一点正义，并提供一些架构审查的背景。 （这里似乎有些混乱）
这些潜在候选人中的每一个都包括许多不同的类别。 这些类别的总体重要性将根据业务需求而有所不同。 恕我直言，没关系。 在通过检查清单进行检查并排除问题时提出另一个问题，而不是完全错过某个问题或类别的成本要低得多，因为它看起来似乎不够重要，不足以将其包括在检查清单中。
- Alexander Nowak撰写的“ 软件架构评论指南 ”
- Tom Verhoeff撰写的“ 审查build筑devise文件清单 ”
- Microsoft模式和实践开发人员中心的“ 清单：架构和devise审查 ”
- “ 概念架构清单 ”Craig Borysowich
- 由JD Meier，Alex Homer等撰写的“ App Arch Guide 2.0 Knowledge Base：Checklist – Architecture and Design ” （通过Peter Stuer的链接find）
- 来自Open Group的“ TOGAF架构合规检查清单 ”
- “ build筑评论过程 ”由Ricky Ho
关于这个话题，似乎还有一篇白皮书，虽然我没有看过。 它试图在大约11页的过程中回答这个问题。
- build筑评论： Maranzano，Rozsypal等人的实践和经验
另外一位同事推荐了一套Springer的书，虽然我自己也没有检查过这些书：
- Springer公司的企业工程系列
你将如何testing它
还有一些要考虑的问题：
- 是否所有的利益相 （例如：客户，最终用户，业务分析师，用户界面devise人员，开发人员，testing人员，维护人员）。
- 架构如何解决安全问题？
- 是否规定了可用性和可靠性的要求？ 架构如何解决这些问题？ （例如：平均无故障时间，平均修复时间。）
- 如何处理灾难恢复？
两本好书为更多的想法：
- 软件系统架构由尼克Rozanski和Ein Woods
- 软件架构实践中的Len Bass，Paul Clements和Rick Kazman
它使用SOLID原则吗？
该架构是否符合技术厂商的指导和路线图？
你想从你select的平台获得支持，而不是打架。
例如，对于以Microsoft为中心的解决scheme，这意味着logging您的select偏离Microsoft体系结构指南的位置和原因。
是否有一个人可以对架构负责？（1）对build议的架构有足够的技术知识;（2）pipe理事物的经验;（3）站在公司内部，这样他的决定就不会被pipe理层所忽略，知道一件事情。
由于（2）和（3）不是真的依赖于架构，我会find这个人，问他想做什么。
现在假设你是那个人（这个问题在你的问题中不是很明显 – 只有当你认为你还会继续担任这个东西的首席架构师时），我会听取Joel On Software的build议写博客并写出devise规范，包括计划，目标，客户，解释deviseselect，一切。 这应该清楚的看法。
后来的想法
我试着想一些你在编写规范之后可能会问自己的问题，比如“是否容易更新项目”，“是否允许最终目标具有灵活性”，“是否可以让事情变得简单支持“，”是否存在安全问题“等等，但是提出这样的问题是值得的，我不认为它们可以用于任何”评估“，因为除了滤除明显的错误之外我不认为有任何具体的问题会对“评估build筑”有所帮助。 也许你的问题会从重新安排中受益？
