面向对象设计是否对象的行为应该和业务强耦合?

malie0 发布于 07/21 09:56
阅读 126
收藏 0

华为云11月刊推送:DIY微信问答机器人,高性能计算代码的20个技巧!>>>

公司一个业务线的产品在设计的时候把业务相关的操作在domain这一层嵌入的很深,里面的很多基础方法都做了业务处理,导致后面有项目借用这个业务框架做开发的时候碰到很多坑,在底层要把很多业务相关代码剥离掉.我一直倾向于值对象应该简单,不要和业务耦合在一起,这样框架的复用性才高,业务处理应该放在service层或者dao层的业务相关处理方法中,不知道大家所在公司的框架设计思路是怎么样的?

加载中
1
Simmy
Simmy

老生常谈的问题,有个话题叫:Anemic Domain Model vs Rich domain model

推荐先了解下DDD和Martin Fowler的相关文章吧

https://martinfowler.com/bliki/AnemicDomainModel.html

https://www.ituring.com.cn/article/details/25

https://www.jianshu.com/p/f4c447b49159

 

  • DDD的Domain层是包含业务逻辑的
  • DDD的Service层不包含太多逻辑,更多是统一接口/入口,分配/协调职责
  • 区分值对象(Value Object不是实体)和实体对象:值对象就是用来传参的,实体对象是包含其代表的责任的

个人意见,最终要解决的重点问题是:代码组织、代码职责划分、代码逻辑复用。看团队整体理解能力,选用适合的方法就可以。

m
malie0
感谢,其实本质就是你说的这个问题,也是我对贫血和充血模型的看法。面向对象设计的理论和实践还是有一定差别的。
0
纳兰清风
纳兰清风

你的理解是对的,dao层都不要有业务处理

m
malie0
我觉得dao层可以设计一个通用的basedao,然后各个业务层的dao继承basedao,业务模块可以在自己的dao中做一些与业务相关的处理,但是不应该重写basedao方法,导致后面每隔业务调用dao的基础方法时候都要去查是否有重写这个方法,造成了业务dao层的调用方法定义不清晰
返回顶部
顶部