从编程思想到软件开发和设计能力培养( 三 ) 在和开发团队沟通的时候

对于我们使用的分层框架基本运行机制和逻辑了解清楚后，基于拿到业务功能需求要开始思考的就不是框架和分层的问题了，而是我们应该在每个分层中设计哪些类？每个类应该有哪些核心方法？类和类之间如何衔接和实现内部调用。单表功能做多了最容易犯错的地方就是完全的数据库表式思维模式，即任何一个数据库表都会有对应的展现页面，控制类， service类和dao类，完全一对一映射和调用。在这种思维模式下忽略了最前面思考的对象的本质，在领域模型里面一个核心就是我们关心的是有明确业务含义的对象，而不是数据库表。数据库表和dao层只是在最终持久化要做的事情而已。
核心功能实现
基于上面的分析可以看到，对于订单创建的时候供应商信息的获取应该是供应商类完成的职责，对于采购类型可能则是一个数据字典的common类完成的职责。而对于核心的订单类可以看到，我们需要的领域服务或方法很简单，即：
public void savePurchaseOrder(COrderEntity order);
订单应该作为一个核心的领域对象来处理，但是实际在后台操作则涉及到OrderHeader和OrderDetail两张数据库表，任何一张订单的保存都涉及到对两张数据库表的操作。
可以看到如果对应的业务功能没有明确的对订单明细的操作规则和方法，那么在Service层没有必要根据头和明细定义两个Service类，只需要一个OrderService类即可。在该类中实现所有的订单保存前数据准备和逻辑校验。
在这一个步骤想清楚后，即对于订单新增功能可以看到，即在页面和展现层进行新增订单操作，在点击保存按钮的时候应该将页面上的订单数据信息传递到action层进行基本的数据完整性校验，然后再将订单数据以json或已经实例化好的订单实体类传递到逻辑层的savePurchaseOrder方法去处理。而savePurchaseOrder要做的事情就是进行数据准备和转换，再调用Dao层的订单头和订单明细保存方法进行数据保存，并控制好事务处理。
基于该逻辑思路我们就基本可以写出各个分层的核心方法和方法实现，实现最基本的订单保存功能。在整个过程中我们始终围绕订单这个核心对象展开。逻辑层的savePurchaseOrder这个方法是核心，即从展现层准备好订单实例数据，从该层到Dao层是实现数据最终的持久化和事务控制。
扩展业务规则实现
对于业务规则可以分为两类规则，即一类规则是数据参考完整性规则，比如数据类型，数据的长度， 2个数据属性间简单控制逻辑（比如订单类型为A时候，发运地址必须输入等）；还有一类即较为复杂的数据处理规则或需要调用后台数据库实现的控制逻辑（订单总金额>1000的时候用户信用等级必须>B级，在订单保存前还需要再实时检查商品库存信息是否足够等）。对于两类规则的基本原则就是第一类可以在action层实现，而第二类数据则需要在业务逻辑层来实现。
对于逻辑层的savePurchaseOrder方法最终应该相当简单，即首先进行业务规则教育，在通过后再调用订单保存方法进行订单保存操作。类似如下：
//采购订单保存方法public void savePurchaseOrder(COrderEntity order) {//对订单相关的业务规则进行逐个校验if !validBusinessRule1(order)return;if !validBusinessRule2(order)return;//校验通过后调用订单保存方法saveOrderInfo(order); }在该实现中可以看到首先进行了子方法的拆分，保持订单保存方法本身的简洁和代码可读性。其次需要考虑对于拆分的处理规则的方法是否需要拆分到单独的业务规则类里面。
这里要看情况来处理，即对于业务规则本身有比较高的复用性时候最好拆分为单独的业务规则类来处理（比如在订单分发或订单拆分业务功能中仍然需要使用同样的业务规则，那么规则单独拆分到类是有必要的），如果功能确实够简单也可以考虑不拆分。