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

现在做项目大都是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---------------->业务数据存储对象

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

是基于表来分的么？

是根据业务抽象出来的职责来分的,这个思考范围内暂可以把数据库忘了，它现在就是一个抽象的存储工具,其实需要操作的主表就二三个