本文主要作为笔者阅读
Eric Evans的《Domain-Driven Design领域驱动设计》
一书，同时拜读了我司大神针对业务代码封装的一套业务框架后，对于如何编写复杂业务代码的一点粗浅理解和思考。
ps,如有错误及疏漏，欢迎探讨，知道自己错了才好成长么，我是这么认为的，哈哈~
背景介绍
忘记在哪里看到的句子了，有 “看花是花，看花不是花，看花还是花” 三种境界。这三个句子恰好代表了我从初入公司到现在，对于公司代码的看法的三重心路历程。
学习动机
“看花是花”
得益于我司十几年前一帮大神数据库表模型设计的优异，一开始刚进公司的时候，很是惊叹。通过客户端配配属性，一个查询页面和一个资源实体的属性控件页面就生成好了。
框架本身负责管理页面属性和查询页面的显示内容，以及右键菜单与 js 函数的绑定关系，同时当其他页面需要调用查询及属性页面时，将页面的实现和调用者页面做了隔离，仅通过预留的简单的调用模式及参数进行调用。这样复杂功能的实现则不受框架限制与影响，留给业务开发人员自己去实现，客观上满足了日常的开发需求。
我司将繁杂而同质化的查询及属性页面开发简化，确实客观上减轻了业务开发人员的工作压力，使其留出了更多精力进行业务代码的研究及开发工作。
这套开发机制的发现，对我来说收获是巨大的，具体的实现思路，与本文无关，这里就不作过多赘述了。
这种新奇感和惊叹感，就是刚开始说的 “看花是花” 的境界吧。
“看花不是花”
那么 “看花不是花” 又该从何说起呢？前面说了，框架完美的简化了大量重复基础页面的开发工作，同时，框架本身又十分的克制，并不干涉业务代码的开发工作。
但是从客观上而言，业务代码本身由于包含了业务领域的知识，复杂可以说是先天的属性。随着自己工作所负责业务的深入，接触更多的业务必然也不再是框架所能涵盖的资源查询与属性编辑页面。
同时考虑到业务编写人员本身相对于框架人员技术上的弱势，以及业务领域本身具有的复杂性的提升，我一开始所面对的，就是各种的长达几百行的函数，随处可见的判断语句，参差不齐的错误提示流程，混乱的数据库访问语句。在这个阶段，对业务代码开始感到失望，这也就是之后的 “看花不是花” 的境界吧
“看花还是花”
有一天，我突然发现面对纷繁而又杂乱的业务代码，总还有一个模块 “濯清涟而不妖”，其中规范了常用的常量对象，封装了前后端交互机制，约定了异常处理流程，统一了数据库访问方式，更重要的是，思考并实现了一套代码层面的业务模型，并最终实现了业务代码基本上都是几十行内解决战斗，常年没有 bug，即便有，也是改动三两行内就基本解决的神一般效果
（有所夸张，酌情理解：P）
。
这是一个宝库。原来业务代码也可以这么简洁而优雅。
唯一麻烦的就是该模块的业务复杂，相应的代码层面的业务模型的类层次结构也复杂，一开始看不太懂，直到我看了
Eric Evans的《Domain-Driven Design领域驱动设计》
才逐渐有所理解。
因为此内部业务框架做的事情很多，篇幅有限，这里仅对最具借鉴意义的领域建模思考作介绍。
业务场景
我主要负责传输网资源管理中的传输模块管理。这个部分涉及相对来说比较复杂的关联关系，所以如果代码组织不够严谨的话，极易绕晕和出错，下面以一张简单的概念图来描述一下部分实体对象间的关联关系。
如图，简单来说时隙和通道是一对多的父子关系，同时业务电路和多段通道间的下级时隙，存在更复杂的一对多承载关系。
所以这个关系中复杂的地方在哪里呢？理解上经常会绕混，电路创建要选多段通道时隙，通道本身要管理多个时隙。这样时隙和通道以及电路同时存在了一对多的联系，如何去准确的理解和区分这种联系，并将之有效的梳理在代码层面就很需要一定技巧。
稍微拓展一下，改改资源类型，把业务电路换为传输通道，把传输通道换为传输段，这套关系同样成立。
另外，真实的业务场景中，业务电路的下层路由，不仅支持高阶通道，还支持段时隙，端口等资源。
整体设计
从业务场景中我们可以看到，资源实体间的模型关系其实有很多相类似的地方。比如大体上总是分为路由关系，和层级关系这么两种，那么如何才能高效的对这两种关系进行代码层面的建模以高效的进行复用，同时又保留有每个资源足够的拓展空间呢？
传统思路
我们先来考虑一下，按照传统的贫血模型去处理传输通道这个资源，针对传输通道的需求，它是如何处理的呢？
最粗陋的常规模型，其实就是依据不同类型的资源对需求进行简单分流，然后按照管理划分 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<String,String> condition = new HashMap<String, String>();
condition.put("channelID",channelId);
condition.put("min_index","0");
condition.put("max_index","1");
boolean flag=true;
List<Map<String,Object>> 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<Map<String,Object>> syss=this.channelJdbcDao.findSysByChannel(channelId);
for(int i=0;i<syss.size();i++){
if("56".equals(syss.get(i).get("SYS_TYPE").toString())){
List<Map<String,String>> paramLists = new ArrayList<Map<String,String>>();
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 行变成了十来个几十行左右的小方法，重新组合。
方案局限
小结
站在分层的角度思考下，上述流程按照技术特点将需求处理逻辑分为了三个层次，可是为什么只有 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
<OperationResEntity> 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
对象，调用相关的方法组合实现自己的业务逻辑以实现复用。
那么这种效果又是如何实现的呢？
概念揭示
首先我们得思考一下，作为一个类而言，最重要的本质是什么？
答案是数据和行为。
照这个思路，对于一个业务对象，比如传输通道而言，进行分析：
那么在具体的业务建模时又该如何理解这两点呢？
答案就是这张图：
可以看到大体分为了三种类型的元素，
-
程序启动时，开始持有各个 DataOperation 对象
-
程序运行时，负责创建 Entity 对象，并将相应的 DataOperation 对象装配进 Entity 对象实例中
Entity(实体对象)：每个用到的资源对象都生成一个 Entity 实例，以存放这个对象特有的实例数据。
DataOperation(数据操作对象)：不同于 Entity，每类用到的资源对象对应一个相应的 DataOperation 子类型，用以封装该类对象特有的数据操作行为
ps，虽然我这里画的 Entity&DataOperation 对象只是一个方框，但实际上 Entity&DataOperation 都有属于他们自己的 N 多个适用与不同场景的接口和模板类
数据管理
笔者是个宅男，因为并木有女朋友，又不喜欢逛街，所以买东西都是网购。这就产生了一个很有意思的影响——隔三差五就要取快递。
可是快递点大妈不认识我，我也不是每天出门带身份证。这就很尴尬，因为我每次总是需要和大妈围绕 “Thehope 就是我” 解释半天。
所以每次解释的时候，我都在想，如果我带了身份证或者其他类似的证件，该有多方便。
什么是 Entity
我们一般认为，一个人有一个标识，这个标识会陪伴他走完一生（甚至死后）。这个人的物理属性会发生变化，最后消失。他的名字可能改变，财务关系也会发生变化，没有哪个属性是一生不变的。然而，标识却是永久的。我跟我5岁时是同一个人吗？这种听上去像是纯哲学的问题在探索有效的领域模型时非常重要。
稍微变换一下问题的角度：应用程序的用户是否
关心
现在的我和5岁的我是不是同一个人？
—— Eric Evans《领域驱动设计》
简单的取快递或许使你觉得带有标识的对象概念并没有什么了不起。但是我们把场景拓展下，你不光要完成取快递的场景，如果你需要买火车票呢？如果还要去考试呢？
伴随着业务场景的复杂化，你会越来越发现，有个统一而清晰的标识概念的对象是多么的方便。
再来看看 Eric Evans 在《领域驱动设计》如何介绍 Entity 这个概念的：
一些对象主要不是由它们的属性定义的。它们实际上表示了一条“标识线”（A Thread of Identity），这条线经过了一个时间跨度，而且对象在这条线上通常经历了多种不同的表示。
这种主要由标识定义的对象被称作 Entity。它们的类定义、职责、属性和关联必须围绕标识来变化，而不会随着特殊属性来变化。即使对于哪些不发生根本变化或者生命周期不太复杂的 Entity ，也应该在语义上把它们作为 Entity 来对待，这样可以得到更清晰的模型和更健壮的实现。
确定标识
得益于我司数据库模型管理的细致，对于每条资源数据都可以通过他的规格类型id，以及数据库主键id，获得一个唯一确定标识特征。
如图：
这里举出的 Entity 的属性及方法仅仅是最简单的一个示例，实际业务代码中的 Entity，还包括许多具备各种能力的子接口。
引入Entity
如图：
可以看到 entity 对象实际上分为了两个主要的接口，RouteEntity 和 HierarchyEntity。
其中 RouteEntity 主要规定要实现的方法是 addRoute()， 即添加路由方法
其中 HierarchyEntity 主要规定要实现的方法是 addLowerRes() 与 setUpperRes() ，即添加子资源对象和设置父资源两种方法。
那么这两个接口是如何抽象建模得到的呢？
确定功能的边界
从微观的实例对象层面来看
因为每个实例都可能拥有完全不一样的路由和层级关系，所以我们建模时候，用抽象出的 Entity 概念，表示哪些每个需要维护自己的属性/路由/层次关联数据的对象实例。
从高一层的类的层次去分析
我们可以发现，对路由的管理，对层次结构的管理，贯穿了传输电路，传输通道，传输段，传输时隙等很多业务类型。所以这个时候就需要我们在接口层面，根据业务特征，抽象出管理不同类型数据的 Entity 类型，以实现内在关联关系的复用。
因此我们对 Entity 接口进行细化而建立了的 RouteEntity 和 HierarchyEntity 两个子接口，比如
-
Entity 需要维护自己的 id 标识，属性信息。
-
RouteEntity 就需要内部维护一个路由数据列表。
-
HierarchyEntity 就需要维护一个父对象和子资源列表。
这样通过对不同的 Entity 管理的数据的职责与类型的进一步明确，保证在不同场景下，做到使用不同的 Entity 就可以满足相应需求。。。。的数据前提 ：P
