在讨论分层架构的过程中，我们常常会被问答一下几个问题：
- 1: 是否需要前后端分离，什么时机分离
- 2: 是否需要服务化，什么时机服务化
- 3: 是否需要引入DAO层，什么时机引入
- 4:是否需要抽取通用中台业务，什么时机抽取
同道们的这些提问，其实很难回答。在不了解业务发展阶段，业务规模，数据量并发量的情况下，妄下YES或NO的结论，本身就是不负责任的。下面我给出一些，我们架构演进的一些观点，同时也经历过系统的一系列的拆分，随便说说自己的感悟。
1 单体应用阶段（第一节段）
如上图所示，为应用在单体应用的时候的一般架构图(我们用的技术框架以流行的ssm为例子) 这时候的应用简单，需要的资源少，可以完全支撑起简单的业务，这时，我们的包应该会这样的划分使用的，比如我们有3张表A,B,C 这时就与对应的3个entity, 我们完美的想法是entity与表字段是一 一队应的(注意：是完美构想)entity 分别是A,B,C 这时也有对应的Mapper接口 对应的CURD,AMapper, BMapper, CMapper, 在业务层的service，我们也会有这样的划分Aservice（AserviceImpl）,Bservice(BserviceImpl), Cservice(CserviceImpl)。 此时，我们规定AserviceImpl-->AMapper, BserviceImpl-->BMapper,CserviceImpl-->CMapper,我们是绝对不允许AserviceImpl-->BMapper这种情况发生的，只能AserviceImpl-->Bservice。这样会有利于后期服务化应用的拆分，不会产生胶水代码。 当然，这种情况往往是我们想象的完美情况，但是实际中我们应用的发展，不会这样的，比如，我们有一个统计功能，需要left join A表和B表，这是后，会在entity 中添加一些非表的属性所有的字段，或新增一个DTO的实体来处理这种情况，而保留entity 与DB 表的一一对应的纯洁性，保持纯洁性以有利于我们对业务的梳理。此时 service 层可能会增加一个Manager层的包，处理各个service的数据聚合的业务处理。manager层中的包不会含有Mapper。
如果此时业务量在迅猛发展(公司资金流和人口红利大)，需要加入缓存来解决一系列业务的时候，可以考虑拆分的问题。
这个阶段可能会遇到的问题，以及解决方案：
| 问题 | 解决方案 |
|---|---|
| restful-code | 链接1 |
| MySQL 使用自增ID主键和UUID | 链接1 |
| 单JVM事务传递 | 链接 |
2 两段式架构
如果要实施服务化，他的架构可能是这样的：
- 客户端：型调用方是browser或者APP
- 站点应用层（web-service）：实现核心业务逻辑，从下游获取数据，对上游返回html或者json
- 业务层(mod-service): 提供服务的业务处理的。
- 数据-缓存层：加速访问存储
- 数据-数据库层：固化数据存储（可能不是RDBS）
这个阶段会遇到的问题，以及解决方案：
| 问题 | 解决方案 |
|---|---|
| spring事务 | 单JVM事务 |
3 三段式架构
注意，架构分层越多，维护层本就越大，资源的费用也是越大的，这是团队不断快速发展，增加人手，快速迭代的分层演进。
这个阶段会遇到的问题和解决方案：
| 问题 | 解决方案 |
|---|---|
| 跨应用的事务处理 | 链接1 链接2 |
| 业界难题-“跨库分页”的四种方案 | 解决方案 |
4 业务方案
| 问题 | 解决方案 |
|---|---|
| 淘宝网商品SKU系统设计经验分享 | 链接 |
| 提一个问题，单JVM 跨库 的替代事务的方案，和 跨应用多JVM的替代事务方案， 有区别性的考量吗？ | 待补充 |
参考
来源：oschina
链接：https://my.oschina.net/u/1187675/blog/1575880