作者：王森
来源：https://www.cnblogs.com/wangsen/p/5052068.html
分层思想的演化是根据实际业务的需求不断改进而来的，下面就来讨论一下我们公司分层架构思想的演化历程：
第一阶段【大杂烩】
一开始我们做专案不会考虑很多东西直接一个专案搞定。
不管是后台管理系统，前端业务，还是使用者登陆系统全部都放到了一个专案中去做。
第二阶段【webapp层】
按照上面的做法会遇到一个问题，如果其中使用者登入出现错误就会全部不能够访问，后来就要求将前端的业务，后台管理系统，以及使用者登入要求分布，这个时候就采取分散式啦。
按照上面的做法的确可以实现三个不同的应用相互不受影响，即使后台挂啦，前台业务和登入也可以使用。
到目前为止webapp层就浮现啦，给该层的定义是：
为互联网使用者提供对外服务，在这层的每一个专案都有自己不被共享的业务。
第三阶段【business层】
在实际应用中我们发现一个问题：Aweb应用和Bweb应用中存在公用业务流程，怎么处理？
如图：
我们的做法是将a业务流程抽取出来。
如图：
比如：我们专案中课程专案和电视端视讯课程专案都会使用订单相关的业务，
那么我们的做法是将公用的业务单独建立一个专案（jar包）的形式，让web应用引用就行啦，当然这不是唯一的解决方案。
如图：
其实到这里我们另一个分层就出来啦：business层
给该层的定义：该层的专案必须是一个提供“共享”业务流程。
第四阶段【base层】
但是这么划分专案也引发了另外一个问题:A business专案和B business同时共用一个资源的时候我们怎么做？？
比如：订单business专案和单点登入business专案都需要使用到使用者相关的服务，我们不可能每一个business专案都写一套相同的程式码，
我的做法是将使用者提供的相关服务单独作为一个专案如：
其他专案可以引用使用者提供服务的专案如：
这样我们就已经解决了多个business专案共享同一份资源的问题，避免了每个应用都重复造轮子。
其实到这里我们的另外一个分层就出现了：base层
我们给该层的定义是：该层中的专案有且只能代表一个真实存在而且能独立存在的核心实体对应的业务。
详细解释一下：
真实存在：可以用一个具体的客观物体承载的，比较聚合的概念。比如：使用者，课程，试题
不是说一个使用者实体就是对应一个base专案，而是我们在对使用者进行面向物件分析和抽象的时候抽取出来的所有相关的
物件都属于这个base专案。
如：
这里的实体全部是与使用者这个抽象概念有关的，比如：学生实体，老师实体，使用者详细实体，使用者实体等等。
第五阶段【core层】
在开发的过程中，我们发现不管是webapp层，business层还是base层都会用到一些和业务无关的服务，比如：数据库持久，redis快取,http封装，通用工具等。
我们根据这些服务的特征单独出去来多个专案，我们称之为这层为core层:
这层的定义：
这层的专案与业务没有关联的，只提供基础能力。
第六阶段【使用】
到现在webapp层，business层，base层以及core层已经划分完毕。那么我们是如何使用这些的呢？？
使用步骤如下：
分析一下，这个产品是否要对使用者独立提供服务，不受其他的产品影响。如果要，则新建web专案。
分析一下，这个产品有没有哪些业务是准备被其他产品使用的，即在其他产品的界面有没有体现本产品。
如果有，分析一下这些公用的业务，有没有包含一个流程性，即它的业务在组合其他已有base专案。如果有，新建一个business专案
分析一下，这个产品有没有可以独立存在，不依赖于任何其他服务的业务。如果有，新建一个base专案。
当实现这些编码时，如果有遇到一些与业务无关的，只提供能力的，则新建一个core专案。
注意：
core层的任何专案其他层的专案都可以直接使用。
同一层的专案可以相互引用。
webapp层的专案不能相互引用，如果有想使用其他的专案服务，可以将那个服务下层到business层中实现。
上层可以跨层依赖下层，比如：webapp层中的专案不仅仅可以引用business层的专案也可以直接引用base层的专案。
