文章目录
前言
最近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