Hello，工程师们，你们有没有饱受代码层次不清晰的困惑，你们有没有经历过随着项目的飞速增长，本来很清晰的结构变得“五彩缤纷”？哈哈哈，我们每个开发老师（称呼源于企业文化）的个性不同，开发的风格不同，有些事情也无所谓对与错这么严格的界定，而CR的时候大部分你也没办法去要求别人按照你的“规章制度”去办事（当然你手握绩效那这里不包括...），所以当新的老师进来的时候，免不了多了一些简单人生的思考，王德发之类的人物名称将在地中海洋里面经常被打印.......
好了废话不多说，切入正题，那我们在面对一个项目之初，或者在你有机会去改变些什么的时候，我们应该如何做呢，这就自然而然的引出了我最近在思考的问题，代码的分层到底该如何设计。
传统的mvc项目来讲（DDD领域驱动的我们下回分解），后端一般会把项目分为这几层，controller（控制器层），service（业务层），dao（数据访问层）各个层级之间的作用顾名思义，这里就不在赘述。其实这中结构看起来简单明了，职责分明。但是往往很多简单的事情碰到了一起，那就会发现其实想要完全掌控全场并不是那么简单，甚至有的时候会有些棘手，不信我们可以看以下几种场景（仅代表个人观点，只要你能跑起来，你就是最棒的呢~~）。
一、各个service之间该如何交互
这个问题我们比较常见，首先按照我个人的开发习惯，controller里面是一定不会写逻辑的，官方点说就是符合SOA的架构规范，私下来说就是我个人比较喜欢controller干净点（强迫症），注释，日志，入参，出参就够了，逻辑交给service，简单校验，异常，链路交给AOP，就算以后项目真的需要进行服务的拆分，那我直接将某个功能提出来就好了，可以做到灵活的可插拔，机动性很高。
那么问题来了，当serviceA 需要用到serviceB的时候，我们应该如何去调用呢？这时候分歧就出现了，不论对错只讲道理，
A：直接调用，不要慌，本来业务间就是可以互相调用
B：直接调用DAO层来解决问题
C: Service分层，下沉公功能部分，也就是说对Service再做一次层级划分
其实这三种方案都没什么问题，没有更好，只有更合适。
先来说A，从业务理解来看没有问题，但是从宏观来看，把service看成单个的服务，那么服务间的调用其实就依赖你初始化的顺序，那这时候其实就对项目有了一定的限制，当然，你如果说我的项目不会走到微服务拆分那一步，那我觉得也没什么问题，毕竟现在idea这么智能，一个find usage 就能知道你这个service用在了哪里。
再来说说B，这种方式其实是比较灵活的，相当于把数据库的访问做了一个打通，让我们每个service在利用任何一份数据的时候畅通无阻，因为我们往往都会把dao单独作为一个模块来引用，所以基本上所有的项目都已访问的到。那么方便是方便了，那么它真的那么优秀吗，其实不然，我们从道义上分析一下，dao是连接数据库的最后一道防线，其实dao提供了出去就相当于把最大的权限给了别人，因为我们大部分都是协作开发，你不知道别人会用你的dao去干什么，所以其实很危险，我们还是建议dao只对自己的service负责，想要拿数据，那么还是去问问service吧，万一有cache，跨库的操作呢，你直接用别人的dao是不是不太合适。
最后我们说一下C，有人会问为啥C放在最后，那必然是我比较青睐的方式，但是不一定适合每个人啊，我们一定要结果导向，能逮到耗子才是好Tomcat啊，跑偏了~。首先这种方式无疑是工作量最大的一种，比较难搞，但是其实我们把体系建立了，自然而然的也就利用起来了，我们需要根据业务去提取公共的功能模块，并将它们下沉到我们的底层，那这时候其实有人就知道了，对我们其实就是在service上面加了一层，我们一般给他们叫做facade，它本意是指外观模式，其实就是一种特殊的service层，加了它就意味着我们的controller只能跟它进行沟通啦，也就有可能发生我们控制层想要用service的某些功能，或许只是查一下数据库，那么也需要在facade层中再做一次透传，所以具体如何取舍，还是要看你业务的发展和架构师对将来项目规模的预估。
结尾来说说我对项目设计的理解，其实这些东西无论对错，有的时候运营和业务其实并不关心你的扩展和维护，他们可能目的会比较单一，就是要他们的产品能够如期上线，至于你的后台如何如何乱，他们完全不care。所以这也就要求我们每个工程师也好，架构师也罢，在理解产品的需求的同时，需要把技术的思维带入，那些业务和那些业务属于一个领域，那些又应该独立的拆分出来，而又有那些业务需求是不符合我们的系统预期的。技术服务于业务，但是不是臣服于业务，更多地还是更好的结合，相辅相成。至于选型，就像充血模型和贫血模型，没有对与错，主要是看团队是不是能把思想保持一致。
网友评论