自己慢慢找回一点面对对象的思想

现在做项目大都是action service dao 三层,
不知为什么现在有点讨厌这种形式了，基本就是面向过程的开发模式，
不管什么东西都往service里放，
最近打算对自己的模块（一个采购接口）模式进行二次重构(之前重构根据多种采购渠道的整合重构过一次)

根据对象职责的分配，细分一些采购涉及的对象;现粗略的抽象出下面的一些职责对象

order------------------------->采购总对象

singlepurhcase --------------->单采购对象，职责，负责一个采购过程的总流水过程

multipurhcaase --------------->多采购对象，职责 ，负责一个订单的多次采购总流水过程

multigoods ------------------->对象责任 选择商品算法

securityorder----------------->对象职责 检验各种采购信息是否正确

purchasemode ----------------->对象职责 执行各种采购形式的后操作

purchasefromXX1 purchasefromXX2 purchasefromXX3
继承purhcasemode-------------->对象职责 ，处理来自不同渠道的采购自定义操作

orderrecord ------------------> 职责 ，记录采购操作过程中各种记录操作

orderparams-------------------> 职责 ,负责采购过程中的采购参数传递

orderutil--------------------->职责 采购过程中工具操作

goods ------------------------>职责 商品实体和商品各种计算操作 如查询类似商品

distribution------------------>职责 商品的分销条件实体和分销实体的各种计算操作

customer --------------------->客服实体，职责 采购过程的客服分配和通知

commistion ------------------->采购过程中订单佣金实现，职责，负责订单佣金的计算

finance----------------------->采购过程中的财务对象，职责，负责订单的财务操作

exeption---------------------->采购过程中的异常对象，职责，负责订单的异常处理

test-------------------------->采购的单元测试对象和整合流程测试对象,职责，确保订单创建过程的正确性

repository---------------->业务数据存储对象

下面一段时间进一步分析重整，
我觉得一个良好的系统的就如一件精密的仪器一样，每个零件在负责好自己的职责外，又能和其它组件良好的协同作业