|
锁定老帖子 主题：要领域模型干嘛？
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-11-26
最后修改：2008-11-27
最近看到一些关于领域模型方面的新鲜玩意，于是和同事朋友们又开始了一些这个方面的讨论。在讨论的过程中，总是被问到，要领域模型干嘛？累死累活的，有必要吗？这个东西有价值吗？东西分开来写不好，非得整个上千行的“domain class”，把所有逻辑放到一起，有必要吗？
是啊，我们这是干嘛呢？大家来补充，反对领域模型的声音都喊出来吧！ —————————— 我承认我炒冷饭，我没有什么新鲜的好炒，我就是炒冷饭，无聊，就是无聊 
—————————— 总结大家的观点和论据： 正方： bloodrate 写道 Domain带来的最大一个好处我认为就是容易测试 尽量将业务运算分散到各个业务类中去，这个实现一整套业务需要的不是一整个事务脚本，而是各个微小业务方法的组合，针对每个方法测试，能更加细致的体现问题。 kebo 写道 领域模型设计最后结果应该是一个网状的类结构，来共同表达领域知识 nihongye 写道 1.实现与模型的分析结果是一致的,没有额外引进分析过程中不存在的service 2.没service+dao+domain那么死板 ronghao 写道 充血不仅对调用者来说简单，而且代码可维护性更好 ray_linn 写道 Domain还是POJO，方法在适当的时候“黏合” 1。模型简单。 2。可测试性强。 反方： ronghao 写道 很多情况下贫血模型是够用的，特别是在很多系统需要共用领域模型的时候，这时候用充血会造成代码的膨胀 joachimz 写道 如果包含流程相关的内容，东西太多，太不稳定。如果不放，似乎又变成了一个只是提供点CRUD操作，最多有一点点validation，似乎很没有必要！ ThinkingInAll 写道 我认为领域模型是固定的，如果你把那些可以变动的逻辑也认为是领域模型里面的逻辑，我觉得是不对的 完善的领域模型里面的逻辑是固定不变的，最起码接口是不变的 那些经常变动的需求，并不能算是'领域'模型里面的一部分 yananay 写道 领域模型，我觉得更大的用途是在分析阶段，而不是在实现阶段。而 ddd，更重要的是帮助你如何去理解业务，分析业务。 downpour 写道 事实上，所谓的把持久化操作，包括查询，修改，保存，都放在领域模型中，只不过是技术上的技巧，并没有在代码上给我们带来质的飞跃。 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2008-11-26
领域模型，不是分开写的吗，非得是一个类的吗？奇怪
|
| 返回顶楼 | |
|
发表时间：2008-11-26
引用 整个上千行的“domain class”，把所有逻辑放到一起
问题是为什么不整理，让代码干净.是领域模型就应该这样?整一整就好了吧 |
| 返回顶楼 | |
|
发表时间：2008-11-26
说实在的，一直不明白该把哪些逻辑放在domain class中。如果包含流程相关的内容，东西太多，太不稳定。如果不放，似乎又变成了一个只是提供点CRUD操作，最多有一点点validation，似乎很没有必要！
|
| 返回顶楼 | |
|
发表时间：2008-11-26
Domain带来的最大一个好处我认为就是容易测试。
Junit,Junit从一开始就有一个很矛盾的地方，那就是：在没有自动测试框架的时候，单元测试原本是白盒测试，因为代码的任何角落都有可能出现问题，这些琐碎问题体现的形式不一，没法抽象出一种统一的模式来测试，Junit出现后Junit仿佛是在用黑盒测试来实现单元测试，一味的asert验证方法的结果，对于那些本该由单元测试中测试的程序代码片断无从下手（现在为止很多人只测试代码覆盖率，比如程序中有一个循环，按照输入条件这个循环应该执行10次，你只能测试执行到了这个循环，至于这个循环是否真的执行了10次无从下手）。所以我认为自动化测试框架所能测出的应该单元测试期测试出现的问题非常有限。所以人们开始为了迎合方便测试而编写可测试的代码，这里来说有点本末倒置了，因为编写业务代码的人员疲惫于业务中，不应该在由他们考虑“我应该怎么封装业务才能更容易测试”这个问题，然而现在这个问题已经在眼前了——尽量将业务运算分散到各个业务类中去，这个实现一整套业务需要的不是一整个事务脚本，而是各个微小业务方法的组合，针对每个方法测试，能更加细致的体现问题。 在通过努力解决Junit和传统单元测试之间的矛盾的时候，IOC配合着领域模型，扮演了让业务单元与应用框架和运行容器解耦的角色，IOC让业务类（Domain）本地化，可以通过本地自动化测试框架进行测试，如果想把测试与开发环境隔绝，也可以建立CC等的自动化测试发布生成报告的服务器，让开发和测试互不干扰。 人总是贪婪的，但是要想实现自动化，就要付出代价。。。 |
| 返回顶楼 | |
|
发表时间：2008-11-27
贫血对象很好用的，在action里充血，试试吧。
|
| 返回顶楼 | |
|
发表时间：2008-11-27
nihongye 写道 引用 整个上千行的“domain class”，把所有逻辑放到一起
问题是为什么不整理，让代码干净.是领域模型就应该这样?整一整就好了吧 引用之前的一位同志的回复 coolnight 写道 http://www.iteye.com/topic/191261?page=8 我们的系统有很多模块组成， 各模块基本上通过数据库来共享信息。 主要的模块大致有： 核心系统（非web）， 网站、 bbs、 网站后台，核心系统后台，BI， 推广员等等 原来的打算是写个rich domain model供各模块来使用，以便代码重用减轻个模块开发的工作量 一个简单的例子， User 原有 changePassword, getFriends, addFriend ... 等等方法 撇开配置以及获取User对象的复杂性不谈， 实际开发中发现， 这些东西重用的地方太少了， 对网站来说很好的rich domain model， 在网站后台里面就麻烦，很多方法在那里根本就是对后台 开发人员的干扰，而很多方法对核心系统、BI等等根本就毫无用处。 而且由于网站之类的web系统， 其功能变化很快， 今天一个样子明天完全有可能是另外一个样子了， 新招个策划都可能提出一堆的改动来， 还有很多临时性的功能， 最后真正在各模块之间共享 的就是最贫血的domain model， 基本上就是表的映射， 连关联都给废了各处自行维护了 如果把逻辑都写到User类里可不是要写个上千行嘛。 |
| 返回顶楼 | |
|
发表时间：2008-11-27
mewleo 写道 贫血对象很好用的，在action里充血，试试吧。
好的定义是什么呢？相比“血”充到领域对象里，充到action里有什么好处呢，又有什么坏处呢？ |
| 返回顶楼 | |
|
发表时间：2008-11-27
bloodrate 写道 Domain带来的最大一个好处我认为就是容易测试。
Junit,Junit从一开始就有一个很矛盾的地方，那就是：在没有自动测试框架的时候，单元测试原本是白盒测试，因为代码的任何角落都有可能出现问题，这些琐碎问题体现的形式不一，没法抽象出一种统一的模式来测试，Junit出现后Junit仿佛是在用黑盒测试来实现单元测试，一味的asert验证方法的结果，对于那些本该由单元测试中测试的程序代码片断无从下手（现在为止很多人只测试代码覆盖率，比如程序中有一个循环，按照输入条件这个循环应该执行10次，你只能测试执行到了这个循环，至于这个循环是否真的执行了10次无从下手）。所以我认为自动化测试框架所能测出的应该单元测试期测试出现的问题非常有限。所以人们开始为了迎合方便测试而编写可测试的代码，这里来说有点本末倒置了，因为编写业务代码的人员疲惫于业务中，不应该在由他们考虑“我应该怎么封装业务才能更容易测试”这个问题，然而现在这个问题已经在眼前了——尽量将业务运算分散到各个业务类中去，这个实现一整套业务需要的不是一整个事务脚本，而是各个微小业务方法的组合，针对每个方法测试，能更加细致的体现问题。 在通过努力解决Junit和传统单元测试之间的矛盾的时候，IOC配合着领域模型，扮演了让业务单元与应用框架和运行容器解耦的角色，IOC让业务类（Domain）本地化，可以通过本地自动化测试框架进行测试，如果想把测试与开发环境隔绝，也可以建立CC等的自动化测试发布生成报告的服务器，让开发和测试互不干扰。 人总是贪婪的，但是要想实现自动化，就要付出代价。。。 为什么把逻辑写到领域模型里就好测试，而写到action/service里就不好测试呢？ |
| 返回顶楼 | |
|
发表时间：2008-11-27
我觉得根据业务需求吧
过于复杂的需求还是用贫血 一般需求用充血 说实话我是喜欢用充血，而这方面ROR里的model做的最好。 充血的model的确更有意义，并且更方便。 你说要领域模型干嘛？可以去比较一下国内的一些面向过程的PHP的CMS，看看如果没有领域模型，是什么样的情况。 |
| 返回顶楼 | |
