公司分层思想的演化历程

分层思想的演化是根据实际业务的需求不断改进而来的，下面就来讨论一下咱们公司分层架构思想的演化历程：

第一阶段【大杂烩】

一开始咱们作项目不会考虑不少东西直接一个项目搞定。

不论是后台管理系统，前端业务，仍是用户登录系统所有都放到了一个项目中去作。

第二阶段【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层的项目。

结合咱们老大的博客相信你会理解的更透彻

基于分布式、服务化的maven项目文件规划