如果你的系统既有web界面,又要暴露remote api,应该怎么分层?

如果你的系统既有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>

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.