其实一个软件系统要不要设计架构，要看实际情况，设计架构的目的是为了解决软件系统的复杂度带来的问题。你在写一个图书管理系统的时候，按照常规的写法即可，没有三高要求，这时候不需要做架构设计，但是当这个图书管理系统管理的是全国所有图书馆时，用户是面向全国用户，那就需要架构设计，因为复杂度完全不同。

在讲设计原则之前，我想先聊一下架构到底是什么？架构和框架有什么关系？系统和子系统有亲戚关系吗？系统和平台那个大？那组件和模块呢？是兄弟吗？

• 系统和子系统

  微信是一个系统，而朋友圈是微信这个系统中的一个子系统，微信支付是也是一个子系统。整体和部分的关系，是有关联的，各个子系统不是独立的。微信支付还可以再分为支付和结算等子系统，当从业务角度不能进行细分时，改子系统就是由组件或模块组成。

• 系统和平台

  系统和平台不能进行大小比较，平台更加侧重于从业务角度来阐述，比如网易云音乐大数据平台，统一权限平台，工业物联网平台等，不同的业务场景来定义各个平台，平台可能是有一个或多个系统子系统组成。

• 模块和组件

  日常对话中，会出现：系统有加密认证模块，平台里面已经有了单点登录模块，下载功能使用的是第三方组件。这里出现的模块和组件是一种泛指的说法，即单点登录可以本身是一个系统，但是在更大的系统中，其也可以是作为该系统的一个组成模块。

  一般来说，我们的组件或者模块是在系统之下的，也就是系统由不同的组件或者模块组成，组件是可复用的单元，内敛的，比如我们写了一个DAO层的组件，用于关系数据库的对象持久化，可以用在不同项目中，只要使用它的API即可；又比如我们写了一个微信登录组件，在用到该功能的系统中，都可以直接拿来使用，并且这种组件是可以替换的，就像一个零件一样。

  而模块更多的是从逻辑角度来定义的，比如上面提到的图书管理系统，可以划分为登录模块，图书管理模块，人员管理模块等。

• 框架和架构

  框架是一种规范，MVC是一种开发规范，JMX，Java Bean等都是，甚至整个JavaEE就是一种规范，框架可以提供基础产品，如Spring MVC 是 MVC 的开发框架，Spring Security、Spring JPA 是Spring提供的基础功能产品。

  架构是创造软件系统时顶层结构设计时的准则，以及对这些结构的描述。有点晕，举个栗子，图书管理系统的架构，指的是该系统的顶层结构，即规定了该系统由那些子系统和组件或者模块来组成，以及他们之间协作的规则。图书管理系统中的登录模块和图书管理模块是有逻辑关系的，即只有登录后的用户才能查看图书，图书模块和登录模块应该是两个不同的模块，逻辑上分开，在线借阅功能应该是放在图书管理模块还是用户模块，这些就是由架构来定义的。

  总之：框架是规范也是约束，可以理解为封闭性的话题，定义好，让别人如何去使用，而架构是一种结构，是一种开放性的话题，如何去设计组织架构，如何让架构更具有拓展性，减少沟通错误成本。