这篇文章想说说目前我在开发项目时，对于项目架构体系的总结。
架构体系图
流程
项目分为客户端和服务端。客户端于服务端进行前后端分离，采用 JSON 进行消息传送，使用 token 来判断用户身份。
客户端发送一个请求到达服务端之后，首先是进行参数验证。因为从客户端传来的数据都是不可信的。如果参数验证不通过，就抛出异常，通过统一的异常处理器将异常返回给客户端。如果参数验证通过，就继续下一步。
这时候数据到达了控制层，也就是 Controller，Controller 判断请求的 URL，对请求进行分发。
接着就是执行业务逻辑。业务逻辑我这里是把 Model 层和 Service 层都放在了一起。Model 层处理简单的业务，Service 是对简单业务的封装以实现复杂的业务。
Model 层和 Service 层在执行业务的时候，会调用数据库进行 CRUD 操作。
对于 Model 层和 Service 的思考
一般来说，大家都是将 Model 层和 Service 层当成是自上而下的结构
Service 层调用 Model 层，然后 Model 层对数据库进行操作。
这样的分层方式很严谨。但是也带来了一个问题。一般来说，我们遇到的项目都是中小型的项目，一直到软件开发的生命周期完毕之后，都不会发现这样写有什么好处。有时候我们只需要执行一个很简单的业务，却需要在 Service 层写一次代码，然后 Model 层写一次代码，最后由 Service 层调用 Model 层。这里的 Service 层仅仅是作为方法转发，代码上非常繁琐。
所以我就想，这样的分层方式一定是对的吗？有必要写这么多的代码吗？
于是，我就将业务逻辑分散到了 Model 层和 Service 层中去。简单的业务写到 Model 层，复杂的业务写到 Service 层。Service 层只是对 Model 层的封装，Service 层遇到复杂的业务时，还是会调用到 Model 层的代码。
异常处理
异常处理在架构体系中也是非常重要的一块。
一般来说异常分为两种：1）自定义异常 2）系统异常。
自定义异常就是用户根据业务而定义的一些异常。比如：用户账号错误异常、权限不足异常等。而系统异常，就是因为代码的 bug 而造成系统出错而产生的异常。
发生了异常，都需要告知客户端。对于自定义的异常，需要告知客户端详细的出错信息同时写入日志。而对于系统异常，只需要告知客户端发生了一些错误，对于详细的错误信息，写入日志即可。
总结
以上就是我对项目架构体系的思考。目前的思考还是很浅显，将来随着项目开发越来越多，思考得也会越多。以后再将本文的内容进行丰富吧。
