浅谈架构——引言

天上盖有如此之国（理想国）之模型，欲之者可见之，见之者可身遵行之。

                                                                                                ——柏拉图《共和国》

什么是架构

      计算机作为一个出生不足百年的新生事物，很多专业词汇都是对已有词汇的重新定义而形成的。架构也是如此。它最早是随着建筑行业而出现的，主要是指建筑的结构、组织和格局。我们看一下这句话里的三个关键词：结构、组织、格局，对应到软件里面的事物应该就是  结构体（层、模块），交互关系以及约束。所以我觉的架构应该是设计人员从最高层次对系统设计的理解，这些理解包含了系统所需结构体的集合、结构体之间的交互关系以及对结构体的约束规则。

        按照3W2H理论，我们解决第一个W，架构是什么。接下来问题就是为什么需要架构、做架构的时候需要考虑哪些方面的事情、什么才是一个好架构。接下来我就试着一一的回答这几个问题。

为什么需要架构

        举个不恰当的例子。做饭  ，平时自己一个人的时候可能随便从冰箱里找点东西收拾收拾就是一顿饭或者干脆点外卖连收拾也不用收拾了。如果想要举办一个宴请或者为女朋友准备一次爱心餐的话，可能需要考虑诸如女朋友喜欢什么，自己做什么拿手，有什么忌口，要不要喝酒，几点开始等等这些问题了。如果不做这些考虑还是像自己一个人的时候一样有什么吃什么。那这顿饭就有很大的概率会被搞砸的。

        同样的道理，软件开发过程中我们所做的任何事情都应该是为了提升项目的成功率而做的。做架构设计也是这样的目的，那么架构为什么能够影响项目的成功率。按照《人月神话》的核心议题系统的本质就是维护系统的“概念完整性”，而一个恰当的架构能够“从顶层到底层维护系统概念的完整性”。从实现的层面来说架构将系统分为有限的几个结构体并且定义了结构体之间的交互关系。每个结构体可以由一个开发人员或一组开发人员来实现。开发人员可以专心关注结构体的实现细节，不需要考虑其他结构体的实现。

做架构的时候需要考虑哪些方面的事情

      一句话概括只要关乎系统的整体质量都属于架构层面的内容，除了宏观的如结构体、数据设计、交互性之外，一些微观细节的东西也会在架构之初进行考虑，如系统的命名规则。

1、架构需要定义系统主要的结构体及其属性，还需要描述它能直接使用哪些模块，可以间接使用哪些模块，不能使用哪些模块。

2、架构需要定义结构体之间的通信规则。

3、架构需要定义系统的数据设计，这里不是指详细的数据库结构设计，而是应该描述数据库的组织结构和内容（是关系型数据库还是NoSQL数据库，是集中还是分散部署，核心数据需要不需要存储在内存），并且能够解释出这样设计的原因。

4、架构应该设计实现数据层面以及代码层面安全性的方法，为系统建立威胁模型，还要考虑内存的保护、关键数据的保护以及非授信数据的处理（表单数据、cookie，外部接口数据）及其他安全相关的事项。

5、架构应该定义量化的性能指标，还要考虑达到性能所需要的资源，对于资源共享的性能指标还应该排出其优先级。

6、架构应该定义系统的交互性，这里不是定义详细的接口，这些接口应该由产品人员根据需求来定义。架构需要定义的是交互的方式、数据格式以及对安全的约定。

7、架构应该定义系统在代码层面的错误处理方式。

什么才是一个好架构

        好架构判断标准可以用六个字来描述就是“高内聚低耦合”。高内聚就是任何一个模块都是由关联性很强的类组成，它们都为实现一个共同的目标而存在。低耦合就是系统内的每个模块都对且只对上下文负责。除了基本的高内聚低耦合外架构一个好的架构还应该具有以下特性。

1、能够清楚的描述系统的主要目标以及针对目标所作出的设计和目标的检测标准。

2、与实现语言无关

3、能够从架构层面保证所有使用架构的开发人员都有一个质量恒定的产出。