软件架构，听起来很神秘，简单来说就是软件系统的整体结构与数据流向，亦可以理解为软件的总体框架，像房子的骨架。架构师把毛坯房建好之后，程序员可以在这个基础上进行具体的装修了。软件架构包括模块（方块）以及模块之间的联系（连线）。在架构一个软件系统的过程中，最明显的一点，就是把握好分与合，恰当的分，根据什么进行拆分，分完之后如何合在一起。
分 包括 分层，分块，分段，分类，分级
这5个 分 ，差不多概括了软件系统的所有拆分方法，这些分法有时候也存在交叉。
分的原则有：
- 关注点分离：这是一个总体的原则，首先搞清楚关注点是什么，不同的角度，关注点不一样，一个例子就是将系统的基础功能代码与领域代码分离开来。如框架提供的基础设施功能（安全，路由，通信等），与具体的业务代码区分开来。
- 单一职责：一个模块只做一件事，主要是拆分函数，拆分类，拆分组件的时候，不要让这些模块太大，功能太多。更纯粹的模块，更容易被外部系统复用，亦即更有价值。
- 动静分离：将未来会变化的代码与未来不会变化的代码拆分开来，未来需求发生改变后，只需改变之前分好的需要改变的部分，之前分离开的静态的代码不用动，以此提高代码的可维护性。整个设计模式，主要是围绕着动静分离来做到解耦的。
- 前后端分离：目前主流的web程序开发方式，将前端的视图层偏展示与交互的东西与后台偏逻辑和数据的代码分离开来，各司其职。
- 公私分离：将公共代码与局部使用的代码分离，如全局style样式，可以共用的header，footer，input组件，把这些代码提取到公共部分
- 抽象与具体分离：这是著名的面向接口编程，抽象的契约（接口）与具体（实现）分离
1-分层
分层偏纵向划分，最典型的分层架构，是网络的通信协议架构，有分7层的（OSI），有分4层的（TCP/IP），不管分几层，都采用了分层，区别是分层的粒度不同。分层之后，上层调用下层，只要接口不变，每一层内部的改变，不会影响其他层。
还有一个经典的分层，是MVC架构，将软件系统分为M（model）数据层，V（view）视图层，C（控制层），
随着前后端的分离，在MVC中的V层又进一步分出MVVM模型
2-分块
分块，是指分成不同的功能模块，偏横向划分，例如前端的js模块化，以及组件化开发，都是将一个大的功能，按照开发视角的关注点，分成一个一个的小的js文件，或者小的独立组件，然后再通过webpack等工具打包合并在一起。分是为了便于开发，合是为了系统运行。分是为了理解和实施，合是为了消费与使用。
3-分段
分段，是从处理流程上进行划分，处理一个事物可以分为很多步骤，将步骤分开，每一步单独处理，例如后端程序普遍采用的中间件技术。以koa为例，在koa中，一切都是中间件，后端服务器，从收到前端的request请求，到发送response响应的过程中，会经历一列的处理步骤，如auth鉴权，validate参数校验，加密解密处理，数据格式转换等步骤。这些处理步骤，在其他的请求响应处理流程中可能也会用到，这个时候将单独的处理步骤分离开来，在其他的处理流程中就可以复用了。
这种处理思想在设计模式上的体现就是责任链模式。
4-分类
分类，是将具有某些共性的具体事物抽象出一个公共的类型出来，在面向对象的编程中，类是核心。 例如，猫、狗、猪、鸟，可以统一分为动物这一大类，而猫、狗、猪又可以进一步划分为哺乳动物这一子类。 为什么要分类呢，我的理解是分类是为了对同一类的事物进行统一处理。就像数据类型，数字3、5在js中都是number类型，进行四则运算是number类型的特性，只要是number类型，都可以统一进行四则运算处理，而'hello'，是字符串类型，字符串类型的数据不能进行四则运算，因此不能对'hello'进行算术意义上的加减乘除。
5-分级
分级，是对同类事物分配一个权重，划分一个优先级，如系统出现问题，bug的严重程度，级别是什么。前端还会听到优雅降级的说法，用于终端兼容的场景，新的好用的特性，终端不支持，此时就启用旧一点的老的能兼容的特性。分层与分级有时会有交叉，公司的职称，p8，p7等是分级，也算分层，级别与层次有时是同一概念。
一个观念：
架构服务于业务。没有统一的架构，没有永恒的架构，没有完美的架构，没有绝对正确的架构。
就像大城市，房子贵，寸土寸金，有蛮多面积小于60平的小户型，在房屋面积强约束条件下，来布局卧室，厨房，卫生间，这个时候得精心考量如何利用小的空间布局出还不错的居住体验，得充分利用墙壁，天花板区的空间，减少空间闲置。而小县城的房子便宜一些，房屋面积基本在100平以上，这个相对大面积的架构布局肯定与大城市的小户型不一样。有钱人，买别墅，别墅的架构肯定又是风格迥异。
举这个例子是为了说明，没有统一的架构，大公司与小公司，业务模型、体量、特征不一样，小公司不能盲目照搬大公司的架构。架构也不是永恒的、一蹴而就、一成不变的，架构需要根据公司战略的调整，业务方向的改变，作出相应的调整，也就是演进式，渐进式架构，要学会进化，适者生存。架构也没有完美的，绝对正确的，不要在刻意追求完美和绝对正确的道路上浪费太多的精力。
观念很重要，一念之间，气象大变。
这是上篇，下篇敬请期待~
