如果你的系统既有web界面,又要暴露remote api,应该怎么分层?
我的回答是:
1. 如果web操作为主,remote api是少数,那就用最常见的web-biz模式;web层不必那么薄,可以通过组装biz services实现use cases
2.
如果remote api为主,web操作为辅,则应该用web-app-biz模式,并且web层不准直调biz层。
==============================================
这张图好理解,也比较容易接受:app层组装biz service并实现校验逻辑,对外暴露服务;web层本身很薄,主要职能是把请求转给app层,校验都不用做。
可能存在的争论是:为什么要禁止web层直调biz层? 两层在同一个系统里(比如同一个JVM里),直调无障碍; 禁止直调的话,如果一个操作不作为remote api对外暴露,仍要在app层中加一层封装的代码供web层调用,岂不是很蛋疼?
这些坏处确实是存在的。但是经验表明,禁止直调带来的好处更多:
1. 系统做大后,出于分工或性能考虑,可能需要把web层剥离为一个独立系统。 如果你禁止直调,分分钟可以完成剥离; 否则,几乎不可能,除非你直接把biz service暴露成remote api(非常不好的做法)。
2. web层直调省不了多少工作量。问自己这样一个问题:校验及报错在哪里做? 非直调的话,校验做在app层,并使用标准的errorCode/errorMessage API返回错误,web层自己不必再校验; 直调的话,web层需要自己做一堆校验,工作量还是有的。
3. 直调时,web层要自己实现校验逻辑和biz service组装逻辑,直接使用domain objects, 这要求web层的开发者也要非常非常清楚业务逻辑;如果不允许直调,web层开发者只须组装request对象和渲染response对象,他可以把精力更多地放在javascript/css上,对业务逻辑只需有所了解即可;也就是说,web层的开发可以轻松外包(对于资源紧张的团队,这一点很有意义)
4. 最严重的问题在于,如果允许直调,对于某些use case,web层和app层可能会实现重复的校验逻辑和biz service组装逻辑。不要小看这些逻辑,可轻可重; 如果没有实现在单一的地方,系统很容易腐化 (违反DRY原则)
==========================================
禁止直调除了要作为开发规范让大家遵守,也应该在技术上作好防卫性设计。如果你用的是maven,可以这样:
<!--web工程的pom.xml--> <dependency> <groupId>some.group</groupId> <artifactId>app</artifactId> </dependency> <dependency> <groupId>some.group</groupId> <artifactId>app-impl</artifactId> <exclusions> <exclusion> <groupId>some.group</groupId> <artifactId>biz</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>some.group</groupId> <artifactId>biz</artifactId> <scope>runtime</scope> </dependency>