|
锁定老帖子 主题：要领域模型干嘛？
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-11-27
taowen 写道 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类里可不是要写个上千行嘛。 User是用户的核心模型，我们可以弄个new SiteUser(user)出来，来封装网站上发生在用户上的操作， 至于合理的模型是什么，按照自己的好坏取向不停改进吧 |
| 返回顶楼 | |
|
发表时间：2008-11-27
那你就是建议用Delegate的方法，给不同的业务模块封装不同的User对象喽。原因是领域模型充血造成肥大。这是不错的想法。
但是还是那个问题，好处是什么？new SiteUser(user)，比起SiteService.xxx(user)，好处在哪里？ |
| 返回顶楼 | |
|
发表时间：2008-11-27
最后修改：2008-11-27
SiteUser不是简单的用委托来理解吧，理解为一个应存在的领域对象吧。
1.实现与模型的分析结果是一致的,没有额外引进分析过程中不存在的service 2.没service+dao+domain那么死板 |
| 返回顶楼 | |
|
发表时间：2008-11-27
nihongye 写道 1.实现与模型的分析结果是一致的,没有额外引进分析过程中不存在的service
2.没service+dao+domain那么死板 第一点很好，也就是Eric Evan所说的ubiquitous language。但是argument可以说，贫血的domain就是已经提供了ubiquitous language中的所有名词。剩下的无非就是一些行为（动词）嘛，那叫commitService还是workflowItem.commit差别不大嘛。我们交谈的时候还是说commit，但是实现不一定要是真的workflowItem支持commit嘛。所以呢，光是这点还站不住脚。 死板不死板，不提供价值。我们要切实地好处。 |
| 返回顶楼 | |
|
发表时间：2008-11-27
说说个人的理解吧。
领域模型，我觉得更大的用途是在分析阶段，而不是在实现阶段。而 ddd，更重要的是帮助你如何去理解业务，分析业务。 实现？对于应用软件来说，复杂度是有的，但是通常情况下并不那么复杂，复杂的是业务，所以，在分析阶段引入领域模型是非常有意义的。 至于楼主讨论的实现方式，我觉得没什么意义，这个冷饭炒得没前几次好。“到底用什么好”->是一个没有答案的问题，不同的场合，不同的规模，会有不同的实现方式。 |
| 返回顶楼 | |
|
发表时间：2008-11-27
fnet 写道 我觉得根据业务需求吧
过于复杂的需求还是用贫血 一般需求用充血 说实话我是喜欢用充血，而这方面ROR里的model做的最好。 充血的model的确更有意义，并且更方便。 你说要领域模型干嘛？可以去比较一下国内的一些面向过程的PHP的CMS，看看如果没有领域模型，是什么样的情况。 过于复杂的需求还是用贫血 一般需求用充血。 没体会到这句话。。。更多的企业级应用上是这样吗？ |
| 返回顶楼 | |
|
发表时间：2008-11-27
最后修改：2008-11-27
我觉得也要根据业务场景来吧。
很多情况下贫血模型是够用的，特别是在很多系统需要共用领域模型的时候，这时候用充血会造成代码的膨胀（对于这种情况，taowen推荐了qi4j）。没有必要只是为了看起来更oo或更爽一些而充血。 但是有些情况下，比如说在工作流系统中，模型典型的都是充血模型，因为模型状态的改变会引起一系列相关模型状态的改变，这种情况下，先调用该模型sette再去查找update其他模型就很bt了，因为这种调用随处可见。此时充血不仅对调用者来说简单，而且代码可维护性更好。 |
| 返回顶楼 | |
|
发表时间：2008-11-27
yananay 写道 说说个人的理解吧。
领域模型，我觉得更大的用途是在分析阶段，而不是在实现阶段。而 ddd，更重要的是帮助你如何去理解业务，分析业务。 实现？对于应用软件来说，复杂度是有的，但是通常情况下并不那么复杂，复杂的是业务，所以，在分析阶段引入领域模型是非常有意义的。 至于楼主讨论的实现方式，我觉得没什么意义，这个冷饭炒得没前几次好。“到底用什么好”->是一个没有答案的问题，不同的场合，不同的规模，会有不同的实现方式。 我还没炒呢……我现在是设立靶子阶段，谢谢。 按照马老大说法，领域模型相对于表模型就是一个前者适合复杂的业务，后者适合简单的业务。但是看见大家的讨论，都是倾向于简单的任务适合领域模型，复杂的话还是把逻辑写到service里比较好。为什么呢？请给出具体的论点。 |
| 返回顶楼 | |
|
发表时间：2008-11-27
ronghao 写道 我觉得也要根据业务场景来吧。
很多情况下贫血模型是够用的，特别是在很多系统需要共用领域模型的时候，这时候用充血会造成代码的膨胀（对于这种情况，taowen推荐了qi4j）。没有必要只是为了看起来更oo或更爽一些而充血。 但是有些情况下，比如说在工作流系统中，模型典型的都是充血模型，因为模型状态的改变会引起一系列相关模型状态的改变，这种情况下，先调用该模型sette再去查找update其他模型就很bt了，因为这种调用随处可见。此时充血不仅对调用者来说简单，而且代码可维护性更好。 不要提前泄露嘛…… 你的观点是，领域模型可以： 1、对调用者更简单（是不是可以理解为使用者更容易发现可重用的行为？） 2、可维护性更好（需要具体论点？） |
| 返回顶楼 | |
|
发表时间：2008-11-27
最后修改：2008-11-27
taowen 写道 那你就是建议用Delegate的方法，给不同的业务模块封装不同的User对象喽。原因是领域模型充血造成肥大。这是不错的想法。
但是还是那个问题，好处是什么？new SiteUser(user)，比起SiteService.xxx(user)，好处在哪里？ 我建议用C#的扩展方法，或者Java用mimix（不知道打错没有），Domain还是POJO，方法在适当的时候“黏合”（C#通过namespace引用）到POJO上，让POJO “充血”，而在充当VO，DTO的时候，POJO又可以“放血”回到“贫血的”状态上。 好处： 1。模型简单。 2。可测试性强。 |
| 返回顶楼 | |
