利用JPA实现充血的领域模型

业务系统的开发中，很多人习惯使用事务脚本(TS, MF，PoEAA)的方式实现领域逻辑。遇到复杂的业务，如果同样使用TS方式，应该也是可以实现的。但是实现的结果是一套复杂的、难以阅读的代码，随着对领域理解的深入和业务需求的不断加强，后果就是维护成本高昂，重复代码变多，测试难以进行。我们经常可以听到这句话：“hi，XX测试人员，这个功能我改完了，但是没有数据或环境太难配置，我没法测试，你在测试环境/uat上测一下吧”。结果很可能是测试人员费尽辛苦准备了一套测试数据，运行到修改的部分后，程序出现异常。这不是最糟的，有时候，运行结果导致测试数据变更，但结果仍然不正确，测试人员还需要准备下一套测试数据（求此时tester的心理阴影面积），这在各系统联调时成本更高。在使用rdbms作为数据存储和JPA作为持久化框架系统中，大多数人遵循这样一个开发流程：
         设计表结构  ->   按表建立实体类 ->  生成每个属性的setter和getter -> 建立一个service和实现类 -> 在service的方法中实现业务逻辑，查询、组合、计算实体需要的属性值 -》 调用实体的setter方法设置值 -> 使用持久化框架提供的方法执行数据最终的持久化。
     这一套流程下来，已经看不到软件设计的影子，完全是针对将要持久化的数据结果进行组合，拼凑，说白了，就是想方设法的计算出表的字段值。如果业务简单，只有简单的CRUD，比如一个字典表的维护，使用上面这种贫血模型应该是很好的选择。谈不到OO，设计之类的软件开发元素。按以上的开发方式看来，业务软件的开发确实不需要什么设计了。    
     实际上