应用程序体系结构清单中应包含哪些内容?

我试图想出一个清单或一组问题/标准来评估和评估提出的或新兴的体系结构(执行体系结构评估)。 在尝试计划,评估或评估一个架构时,您提出的最重要的问题是什么?

我知道这是一个很大的话题,所以我想把它限制在一个端到端的系统中,而不是整个组织的体系结构。

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筑”有所帮助。 也许你的问题会从重新安排中受益?