前后端分离
前后端分离，本质是关注点的分离。软件越来越复杂，需要有人来专注于表现和交互，有人专注于领域逻辑。于是前后端分离出现了。前端关注交互体验，这些看得到摸的着的部分。后端关注于表达正确的业务。有争议的地方就在于controller这一层应该放到前端还是后端。并且随着前后端分离，前后端的协作问题就暴露出来。
Controller在前
这样的项目可以从职能上分为两个部分。
- 服务
提供各种服务，比如领域服务，消息服务，权限服务等。是一个可以独立的对内对外的纯服务，更加重领域建模，重设计。 - 产品
组合服务，提供视图，控制产品的整个生命周期。是一个独立的客户端，通过消费后端服务，提供服务，更重产品。 - 协作
- 独立性：各自可以独立开发，独立部署。
- 依赖：前端需要依赖后端暴漏的服务接口（领域，资源接口，具有一定的通用性，接近数据库）。后端在完成设计的时候，提供服务并且返回mock的数据。在后端调整服务URL，请求方式，请求参数，返回数据时需要通知前端变更。
- 环境：需要一个拥有完整服务的测试环境，前端开发需要调用各种服务，因此需要各个服务都在运行状态。
- 打个比方
这种开发方式，后端就像支付宝公司，前端就像我们的服务。我们按照支付宝的接口约定，调用支付宝的支付服务。
Controller在后
这样的项目一般从文件上进行分拆
- 静态页面部分
前端写js，css，模板； - 非静态页面部分
后端写服务;组合服务，提供视图，控制产品的整个生命周期。 - 协作
- 独立性：各自独立开发，部署在一起。
- 依赖：后端需要配置前端maven依赖(通过maven方式分发前端项目)。前端依赖后端容器（servlet，velocity Context等）提供的数据来填充模板，需要后端提供的业务接口。后端调整服务URL，请求方式，请求参数，返回数据时需要通知前端变更。
- 环境：需要一个拥有完整服务的测试环境，后端需要调用各种服务，因此需要各个服务都在运行状态。
- 打个比方：
这种开发方式，类似后端好比包工头，前端好比搬砖头。前端技术会受限于后端，而后端也会因为需要考虑前端而分散精力，并没有达到关注点分离的效果。
tips:服务接口和业务接口只是为了区分做的事情不同而已。可以简单的理解为离数据库的远和近。离数据库越近，粒度越粗，通用性越好，离数据库越远，越靠近变现层，会更具体，粒度更细，通用性越差。这里服务接口是更靠近数据库。考虑如下的过程：
db(net ram file mq) -> po(持久化) -> do(领域建模) -> bo(业务模型) -> dto(传输对象)
实现和选择
和公司的情况有关系，如果公司没有专业前端，那么选择controller前置的策略。进行项目的拆分，分出服务和应用。技术实现上前端可以选择基于spring mvc（ruby python或其他）的全栈或者基于NodeJS的新的全栈方式。
如果公司有专业前端。那么初期选择controller后置的方式，会是一个自然的选择。以后的进化可以选择NodeJs的全栈开发方式。实现服务和应用的分离。
未来遐想
对于后端人员的JS之路，需要了解浏览器排版规则，浏览器诡异bug，以及各种黑暗魔法，其挑战不可谓不大。而对于前端开发人员的NodeJs之路，需要学习应用开发中的复杂性和各种坑点。这和单单做页面完全是不一样的东西，其挑战性甚至比后端人员学习JS更大。
然而技术归技术，好的交互并非只有技术就够了。预想会有三个只能规划：
- 交互
- 应用
- 服务
时间： 2024-10-13 17:24:20