领域模型 And 事务脚本

       事务脚本和领域模型之间的区别还是很明显的，显然，我们常见的系统中没有太多是采用领域建模来实现的；而大部分是采用事务脚本来实现。

        我承认事务脚本在解决简单问题方面确实是简单，特别是只是简单的CRUD问题。
      
       事务脚本的一个最重要的特征是：

        1. 简单的过程模型。也就是一个Service方法就对应着用户的一个命令，该命令通过行数据入口或者表数据入口来完成取数据操作，以及其它的数据处理操作。

        2. 行数据入口 或者 表数据入口。数据库中的记录对应一个对象，还是查询出来是对应数据库的记录集。行数据入口：为查询语句返回的每一行产生一个它的实例。这也应该是先行的很多ORM工具使用的方法。表数据入口：为查询语句返回一个记录集。对数据库中的每个表，仅仅使用一个对象来管理。

        3. 事务的边界：开始于脚本的打开，终止于脚本的关闭。也就是事务边界就是在Service方法上。

        在项目中，操作方式就是从Service -> DAO -> DB。我们数据库层采用的是ORM映射，数据库表和实体是一一映射关系，和行数据库入口差别不大。对于系统当中只有增删改查的情况，用这种方式相当直观，并且良好，不会有什么问题。

        但是，在系统的业务逻辑比较复杂的地方。虽然，我现在搞不清楚，到底有哪些地方业务逻辑比较复杂。可能最为复杂的地方是在度量吧，度量那部分有很多计算。
       
        一切在后面的发展过程中去看吧。现在不能简单的下结论，只要代码良好，问题都不大。       

评论

3 楼 hiwzg 2007-07-16  

不知道什么样的业务才是负责业务，这个比较讨厌。

2 楼 nwangwei 2007-07-16  

普通应用使用事务脚本模式就足够了，而使用了脚本模式又使用hibernate和jdo反而把会事情搞复杂。

hibernate和jdo还是适合领域模型模式的，而目前就我所知，还是采用事务脚本来实现的应用比较多。

那怎么算普通应用呢？感觉是不觉得维护麻烦的时候都是普通应用，哈哈

比如银行、电信等积累了很多行业规范和操作手册之类的行业应用不算普通应用，其实都是因为业务逻辑比较复杂的缘故。

1 楼 hiwzg 2007-07-09  

领域模型是需求分析的方法，但是，领域模型分析之后得到的模型不能脱离于后面的分析和设计。也就是说，如果分析和设计不能反映模型，或者说是脱离了模型，那么领域分析也就没有用了。

看DDD一书，提到领域驱动的分析和设计，期间比较重要的角色有领域专家，领域专家和开发人员一起建模，得到领域模型，之后设计实现？

那么架构师在什么位置，需求分析人员在什么问题呢？我认为架构师应该是要和领域专家在一起进行领域建模，这个时候既属于需求的分析，又能够提炼出领域模型，架构师得出足以指导开发人员进行详细设计的架构设计，然后经过设计评审，就可以得到相对比较好的设计了。