分层思想的演化是根据实际业务的需求不断改进而来的，下面就来讨论一下我们公司分层架构思想的演化历程：
第一阶段【大杂烩】
一开始我们做项目不会考虑很多东西直接一个项目搞定。
不管是后台管理系统，前端业务，还是用户登陆系统全部都放到了一个项目中去做。
第二阶段【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层的项目。