Java Web开发中Maven是不可或缺的管理组件，贯穿代码骨架工程搭建、依赖管理、测试、打包以及二方库发布等环节。然而，使用Maven搭建骨架工程时，模块的划分并没有统一标准，于是我经历过的项目组看到了两个极端的划分。其一：大一统，一个pom模块加一个web模块，基本丧失了模块管理的作用；其二：划分过细，层层嵌套，增加了开发工作的复杂性。那如何在这两个极端中找到平衡方案呢？本文我从以下两个方面做了阐述，欢迎大家批评指正。

01 Java Web分层开发模式概述

分层模式是比较经典的开发模式，我试着从分层模式的特点，找到我们模块划分的依据。通常我们的系统是基于用户请求和响应进行交互的，从用户发出请求，到系统做出响应，在分层开发模式下，java代码的执行过程如下图所示。

1-1 分层开发模式请求&响应示意图

基于响应链的过程（基于请求链也无不可），从持久化数据库（后）到用户UI界面（前），我们可以粗略的将java代码做Dao、Service和Controller三层划分。

1-2 三层划分示意图
而通常Controller的作用无外乎:

1）请求转发（route）
2）视图渲染（view render）

因此，业务逻辑的实现最终会放到Service和Dao层。从这个意义上来讲，我们可以进一步抽象，将系统划分为web层和业务逻辑处理层（Service）。

1-3 进一步抽象的两层划分示意图

其实作为主流的J2EE框架，SpringMvc容器也是按照这两层来划分的，每个DispatchServlet实例都有自己的上下文，且持有spring父容器的上下文。

1-4 springMvc的父子容器示意图

02 Service层的“开放-闭合”原则（OCP）

说是原则，不如说是我们软件开发过程追求的目标

面向扩展开放（Open For Extension）
面向修改封闭（Closed For Modification）

那实现这个目标的具体手段有哪些呢？在我看来除了控制成员变量和方法的可见性，就是我们一直倡导的——面向接口，隐藏实现。这里不再论述这个原则的好处，接下来进入正题，来讲基于以上两点的分析，我们得出来的模块划分方案。

2-1 POM&Intf&Impl&Web四模块示意图

通过这样的模块划分以及依赖关系，我认为至少有以下三个好处。

首先，我们从模块的可见性就很好的对Web隐藏了实现（就如图1-2经典的三层划分而言，Dao也对Service隐藏了实现），继而实现面向接口的编程。
再者，在团队协作开发过程中，即时没有实现，只要抽象好了接口（加好注释），在业务模块互相引用的场景下，也可以并行开发，从而提高开发效率。
最后，相对于层层嵌套的方案，这样扁平化的模块划分，降低了骨架工程和依赖管理的复杂度。

说道这里，我想就面向接口，隐藏实现展开论述一下。

a 区分（接口）能力和（实现）表现

我们在转换需求的时候，必须要能很好的识别出需求中的能力。比如拿“金拱门”为例，可以把它的能力和表现抽象为下面的层次。

a1 对金拱门能力和表现的抽象示意图

b 对能力的“扩充式扩展和增量式扩展”

我们依然拿金拱门为例：

b1 能力面临扩展

那按照图b1的表述，我们可以这么实现：

b2 对能力的“扩充式扩展”示意图
如图，我们为orderMeal接口增加了参数“是否需要打包”（这样比需不需要都打包要好那么一点儿），在OrderMealServiceIntf接口的下面，又抽象出了一个基类OrderAndPackaageServiceAb，由它作为模版来决定是否对食物进行打包。乍一看没有什么问题，但是如果此时用户就“一起打包”和“分开打包”提出需求，那我们就只能再增加参数，并且在OrderAndPackaageServiceAb中去增加实现了。但是如果我们采用“增量式扩展”，则不会有这个问题。
b3 对能力的“增量式扩展”示意图

在这种扩展方式中，我们将“打包”抽象成了一个能力MakePackageServiceIntf，由它作为委托，实现TakeAwayOrderMealService的打包需求。通过这个例子，我们还可以得出以下两个论点：

扩展接口职责尽可能单一，这样才具有可组合性
继承是生死相依，委托是逢场做戏（多交男女朋友，少认干爹干娘）