java 多层结构故障_多层构架在实践中一些问题
打从年初开始，我就已经看到这个问题，但奈何当时自己水平也一般，并没有什么好的解决办法，只是默默的记住了这个问题。
现在终于有所积淀，是时候回馈一波社区了，顺便推广一下 DDD 这个业务代码提升神器~~~
业务场景
我主要负责传输网资源管理中的传输模块管理。这个部分涉及相对来说比较复杂的关联关系，所以如果代码组织不够严谨的话，极易绕晕和出错，下面以一张简单的概念图来描述一下部分实体对象间的关联关系。
如图，简单来说时隙和通道是一对多的父子关系，同时业务电路和多段通道间的下级时隙，存在更复杂的一对多承载关系。
所以这个关系中复杂的地方在哪里呢？理解上经常会绕混，电路创建要选多段通道时隙，通道本身要管理多个时隙。这样时隙和通道以及电路同时存在了一对多的联系，如何去准确的理解和区分这种联系，并将之有效的梳理在代码层面就很需要一定技巧。
稍微拓展一下，改改资源类型，把业务电路换为传输通道，把传输通道换为传输段，这套关系同样成立。
另外，真实的业务场景中，业务电路的下层路由，不仅支持高阶通道，还支持段时隙，端口等资源。
整体设计
从业务场景中我们可以看到，资源实体间的模型关系其实有很多相类似的地方。比如大体上总是分为路由关系，和层级关系这么两种，那么如何才能高效的对这两种关系进行代码层面的建模以高效的进行复用，同时又保留有每个资源足够的拓展空间呢？
传统思路
我们先来考虑一下，按照传统的贫血模型去处理传输通道这个资源，针对传输通道的需求，它是如何处理的呢？
图片描述
最粗陋的常规模型，其实就是依据不同类型的资源对需求进行简单分流，然后按照管理划分 Controller 层，Service 层，Dao 层。各层之间的交互，搞得好一点的会通过抽象出的一个薄薄的 domain 域对象，搞的不好的直接就是 List,Map，Object 对象的粗陋组合。
代码示例
/**
* 删除通道 不调用ejb了
* 业务逻辑：
* 判断是否被用，被用不能删除
* 判断是否是高阶通道且已被拆分，被拆不能删除
* 逻辑删除通道路由表
* 清空关联时隙、波道的channel_id字段
* 将端口的状态置为空闲
* 逻辑删除通道表
* @param paramLists 被删除通道,必填属性：channelID
* @return 是否删除成功
* @throws BOException 业务逻辑判断不满足删除条件引发的删除失败
* 通道非空闲状态
* 高阶通道已被拆分
* 删除通道数据库操作失败
* 删除HDSL系统失败
* @return 成功与否
*/
public String deleteChannel(String channelId){
String returnResult = "true:删除成功";
Map condition = new HashMap();
condition.put("channelID",channelId);
condition.put("min_index","0");
condition.put("max_index","1");
boolean flag=true;
List> channel = this.channelJdbcDao.queryChannel(condition);
if(channel==null||channel.size()==0){
return "false:未查询到通道信息";
}
//判断是否被用，被用不能删除
String oprStateId = channel.get(0).get("OPR_STATE_ID").toString();
if(!"170001".equals(oprStateId)){
return "false:通道状态非空闲，不能删除";
}
//判断是否是高阶通道且已被拆分，被拆不能删除
flag=this.channelJdbcDao.isSplited(channelId);
if(!flag){
return "false:高阶通道已被拆分，不能删除";
}
//逻辑删除通道路由表 并且清空关联时隙、波道的channel_id字段
this.channelJdbcDao.deleteChannelRoute(channelId,oprStateId);
//将通道端口的端口状态置为空闲
this.channelJdbcDao.occupyPort(String.valueOf(channel.get(0).get("A_PORT_ID")),"170001");
this.channelJdbcDao.occupyPort(String.valueOf(channel.get(0).get("Z_PORT_ID")),"170001");
//逻辑删除通道表
this.channelJdbcDao.delete(channelId);
//如果通道走了HDSL时隙则删除HDSL系统及下属资源 ，这里重新调用了传输系统的删除的ejb。
List> syss=this.channelJdbcDao.findSysByChannel(channelId);
for(int i=0;i
if("56".equals(syss.get(i).get("SYS_TYPE").toString())){
List> paramLists = new ArrayList>();
List paramList = new ArrayList();
Map map = new HashMap();
map.put("res_type_id", "1001");
map.put("type", "MAIN");
paramList.add(map);
map = new HashMap();
map.put("sys_id", syss.get(i).get("SYS_ID"));
paramList.add(map);
//EJB里面从第二个数据开始读取要删除的系统id，所以下面又加了一层 。
map = new HashMap();
map.put("res_type_id", "1001");
map.put("type", "SUB");
paramList.add(map);
map = new HashMap();
map.put("sys_id", syss.get(i).get("SYS_ID"));
paramLists.add(map);
String inputXml = this.createInputXML("1001", "deleteTrsSys",
"TrsSysService", paramLists);
String result = this.getEJBResult(inputXml);
if(result==null||"".equals(result)){//如果ejb处理失败是以抛异常形式，被底层捕获而未抛出，导致返回结果为空
return "false:删除HDSL系统失败";
}
Document document = XMLUtils.createDocumentFromXmlString(result);
Element rootElement = XMLUtils.getRootElement(document);
if (!TransferUtil.getResultSign(rootElement).equals("success")){
result =rootElement.attribute("description").getValue();
return "false:删除HDSL系统失败"+result;
}
}
}
return returnResult;
}
上面这些代码，是我司n年前的一段已废弃代码。其实也是很典型的一种业务代码编写方式。
可以看到，比较关键的几个流程是 ：
空闲不能删除(状态验证)—>路由删除->端口置为空闲(路由资源置为空闲)->资源实体删除
其中各个步骤的具体实现，基本上都是通过调用 dao 层的方法，同时配合若干行service层代码来实现的。这就带来了第一个弊端，方法实现和 dao层实现过于紧密，而dao层的实现又是和各个资源所属的表紧密耦合的。因此即便电路的删除逻辑和通道的删除逻辑有很相似的逻辑，也必然不可能进行代码复用了。
如果非要将不同资源删除方法统一起来，那也必然是充斥着各种的 if/else 语句的硬性判断，总代码量却甚至没有减少反而增加了，得不偿失。
拓展思考
笔者曾经看过前人写的一段传输资源的保存方法的代码。
方法目的是支持传输通道/段/电路三个资源的保存，方法参数是一些复杂的 List,Map 结构组合。由于一次支持了三种资源，每种资源又有自己独特的业务判断规则，多情况组合以后复杂度直接爆炸，再外原本方法的编写人员没有定期重构的习惯，所以到了笔者接手的时候，是一个长达500多行的方法，其间充斥着各式各样的 if 跳转，循环处理，以及业务逻辑验证。
解决办法
面对如此棘手的情况，笔者先是参考《重构·改善既有代码设计》一书中的一些简单套路，拆解重构了部分代码。将原本的 500 行变成了十来个几十行左右的小方法，重新组合。
方案局限
重构难度及时间成本巨大。
有大量的 if/else 跳转根本没法缩减，因为代码直接调用 dao 层方法，必然要有一些 if/else 方法用来验证资源类型然后调用不同的 dao 方法
也因为上一点，重构仅是小修小补，化简了一些辅助性代码的调用(参数提取，错误处理等)，对于业务逻辑调用的核心代码却无法进行简化。service层代码量还是爆炸
小结
站在分层的角度思考下，上述流程按照技术特点将需求处理逻辑分为了三个层次，可是为什么只有 Service 层会出现上述复杂度爆炸的情况呢？
看到这样的代码，不由让我想到了小学时候老师教写文章，讲文章要凤头，猪肚，豹尾。还真是贴切呢 :-)
换做学生时代的我，可能也就接受了，但是见识过高手的代码后，才发现写代码并不应该是简单的行数堆砌。
业务情景再分析
对于一个具体的传输通道A的对象而言，其内部都要管理哪些数据呢？
资源对象层面
自身属性信息
路由层面
下级路由对象列表
层次关系层面
上级资源对象
下级资源对象列表
可以看到，所有这些数据其实分为了三个层面：
作为普通资源，传输通道需要管理自身的属性信息，比如速率，两端网元，两端端口，通道类型等。
作为带有路由的资源，传输通道需要管理关联的路由信息，比如承载自己的下层传输段，下层传输通道等。
作为带有层次关系的资源，传输通道需要管理关联的上下级资源信息，比如自己拆分出来的时隙列表。
更进一步，将传输通道的这几种职责的适用范围关系进行全业务对象级别汇总整理，如下所示：
各种职责对应的业务对象范围如下：
同时具有路由和层次关系的实体:
传输时隙、传输通道、传输段、传输电路
具有路由关系的实体:
文本路由
具有层次结构关系的对象：
设备、机房、端口
仅作为资源的实体：
传输网管、传输子网、传输系统
拓展思考
微观层面
以传输通道这样一个具体的业务对象来看，传统的贫血模型基本不会考虑到传输通道本身的这三个层次的职责。但是对象的职责并不设计者没意识到而变得不存在。如前所述的保存方法，因为要兼顾对象属性的保存，对象路由数据的保存，对象层次结构数据的保存，再乘上通道，段，电路三种资源，很容易导致复杂度的飙升和耦合的严重。
因此，500行的函数出现某种程度上也是一种必然。因为原本业务的领域知识就是如此复杂，将这种复杂性简单映射在 Service 层中必然导致逻辑的复杂和代码维护成本的上升。
宏观层面
以各个资源的职责分类来看，具备路由或层次关系的资源并不在少数。也就是说，贫血模型中，承担类似路由管理职责的代码总是平均的分散在通道，段，电路的相关 Service 层中。
每种资源都不同程度的实现了一遍，而并没有有效的进行抽象。这是在业务对象的代码模型角度来说，是个败笔。
在这种情况下就算使用重构的小技巧，所能做的也只是对于各资源的部分重复代码进行抽取，很难自然而然的在路由的业务层面进行概念抽象。
既然传统的贫血模型没法应对复杂的业务逻辑，那么我们又该怎么办呢？
新的架构
代码示例
@Transactional
public int deleteResRoute(ResIdentify operationRes) {
int result = ResCommConst.ZERO;
//1:获得需要保存对象的Entity
OperationRouteResEntity resEntity = context.getResEntity(operationRes,OperationRouteResEntity.class);
//2:获得路由对象
List entityRoutes = resEntity.loadRouteData();
//3：删除路由
result = resEntity.delRoute();
//4：释放删除的路由资源状态为空闲
this.updateEntitysOprState(entityRoutes, ResDictValueConst.OPR_STATE_FREE);
//日志记录
resEntity.loadPropertys();
String resName = resEntity.getResName();
String resNo = resEntity.getResCode();
String eport = "删除[" + ResSpecConst.getResSpecName(operationRes.getResSpcId()) + ": " + resNo + "]路由成功!";
ResEntityUtil.recordOprateLog(operationRes, resName, resNo, ResEntityUtil.LOGTYPE_DELETE, eport);
return result;
}
上述代码是我们传输业务模块的删除功能的service层代码片段，可以看到相较先前介绍的代码示例而言，最大的不同，就是多出来了个 entity 对象，路由资源的获取是通过这个对象，路由资源的删除也是通过这个对象。所有操作都只需要一行代码即可完成。对电路如此，对通道也是如此。
当然，别的service层代码也可以很方便的获取这个entity对象，调用相关的方法组合实现自己的业务逻辑以实现复用。
那么这种效果又是如何实现的呢？
(和编程避免重复代码一样，重复编写一段文字并没有什么价值，这里只是节选，推广下自己的博客，想了解更多还是去我的博客里看吧)