思考面向对象中的开发模型贫血和充血

本文探讨了DDD中的贫血模型与充血模型在实际开发中的冲突,通过A、B、C开发者的案例对比,分析了如何处理模型矛盾和创新应用充血模型。作者强调理解背后的理论并结合团队协作的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >


前言

最近DDD 面向领域设计 比较火,但DDD的真实案例并不多,我自己对DDD的理解也一直在变,但我感觉要把DDD弄懂,可以先来看看 贫血和充血,不妨先思考这个,或许会有所帮助。


名词解释

贫血
是指领域对象里只有get和set方法,或者包含少量的其它方法,与之有关的业务逻辑都不放在该类中,而是放在其它地方,比如Business logic层

充血
充血模型与之不同,不仅有get/set方法,还有业务逻辑也在领域模型(Domain model)里面,Business Logic只是简单封装部分业务逻辑以及控制流程。

参考:
https://cloud.tencent.com/developer/article/1413498

另外,其实还有两种模型 失血和胀血,但因为已经公认不被提倡,就在这里简单知道有就好。


案例分析及展开

角色:A开发

A开发使用贫血模型(传统的开发分层),将用户权限逻辑内聚在 loglic service中,操作user domain 添加用户。
在这里插入图片描述

/**
 * 用户 模型
 */
public class UserDomain {

	String cname;
	String sex;
}

/**
 * 用户 逻辑
 */
public class UserService {

	UserDao userDao;
	
	public void addUser(UserDomain userDomain) {
		//添加用户等相关逻辑....
	}

}

角色:B开发

B开发想学习尝鲜充血模型,将新的任务使用充血模型开发,将判断用户是否有权限的逻辑写在domain里面。
在这里插入图片描述

/**
 * 用户 模型
 */
public class UserDomain {

	String cname;
	String sex;
	
	public boolean isAuth(UserDomain userDomain){
		//确认用户是否有权限
		return true;
	}
}

角色:C开发

最后C开发接到开发,要求对用户的所有操作进行校验 ,这个时候发现不知道怎么开发才合理。

方案1:两边的模型特点都保持

两边都按各自的风格复制一份去实现,代码产生坏味道

/**
 * 用户 逻辑
 */
public class UserService {

	UserDao userDao;

	public boolean verification(UserDomain userDomain) {
		//验证... 
		return true;
	}

	public void addUser(UserDomain userDomain) {
		if (verification(userDomain)) {
			//添加用户等相关逻辑....
		} else {
			throw new RuntimeException("user verification failure");
		}
	}

}

方案2:继续拆解一个抽象逻辑存放

再拆出一个关于用户的逻辑的地方存放,初步一看,挺好的呀,其实充血模型已经完全给破坏了

/**
 * 用户帮助类
 */
public class UserHelper {

	public static boolean verification(UserDomain userDomain) {
		//验证...
		return true;
	}
}

/**
 * 用户 逻辑
 */
public class UserService {

	UserDao userDao;

	public void addUser(UserDomain userDomain) {
		if (UserHelper.verification(userDomain)) {
			//添加用户等相关逻辑....
		} else {
			throw new RuntimeException("user verification failure");
		}
	}

}

/**
 * 用户 模型
 */
public class UserDomain {

	String cname;
	String sex;

	public boolean isAuth(UserDomain userDomain) {
		if (UserHelper.verification(userDomain)) {
			//确认用户是否有权限
			return true;
		} else {
			throw new RuntimeException("user verification failure");
		}
	}
}


一些思考

案例看法,换位思考

1.项目负责人有义务解决团队中的矛盾,首先要解决A开发和B开发的模型矛盾问题;他们本身非常容易陷进各自的思维,认为自己都是对的,这种开发人员的诡辩其实很多情况下是没有结论的,这个时候需要一个裁判,可借用阿里巴巴的 开发手册(华山版,泰山版等等)来解决矛盾(在没有明确的标准下,就按业界的事实标准来)。

2.B开发想要创新,就需要付出更多的努力,首先要对充血模型理解非常深刻,且将自己碰到过的所有难点,都准备好解决方案,再积极沟通,与上级和同事说明情况,在获得认可后找一个新项目试错 充血模型。

最后回到贫血和充血抽象命题

随着一些文章的阅读量的增加,可以感受到不同人的看法和理解,有人说现在的传统分层开发就是贫血的DDD,有人说在贫血的模型外再来一层充血的思想就是DDD。
思来思去,真的是矛盾和和谐并存。为了不迷茫,有待于大家的思考和实践,才能对DDD,越来越清晰。

附上我之前写的博文入口:

[1] https://blog.youkuaiyun.com/vipshop_fin_dev/article/details/89303458
[2] https://blog.youkuaiyun.com/vipshop_fin_dev/article/details/85323076
[3] https://blog.youkuaiyun.com/vipshop_fin_dev/article/details/85239099
[4] https://blog.youkuaiyun.com/vipshop_fin_dev/article/details/79618067
[5] https://blog.youkuaiyun.com/vipshop_fin_dev/article/details/79313432
[6] https://blog.youkuaiyun.com/vipshop_fin_dev/article/details/106862227
[7] https://blog.youkuaiyun.com/vipshop_fin_dev/article/details/108693333
[8] https://blog.youkuaiyun.com/vipshop_fin_dev/article/details/109275465

朱杰
2021-04-25

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值