作为一名java程序员，关于DDD领域模型，很多人可能只是看到项目中划分了Query,BO,DO,DTO,VO等领域类，但却不知道怎么做领域模型，领域模型到底该实现什么东西，以及为什么要用领域模型，他到底是解决了什么问题。
一、为什么要引入领域模型？
领域模型其实是一个概念性的东西，并不是一套完整的标准。具体的使用方式网上也没有完美的正确的讨论结果，无论是贫血模式、失血模式都有其赞同者。在此我们不说什么模式是好的，仅讨论引入领域模型的目的是什么。领域模型是为了让业务更明了，让代码更清晰，是为了优化代码结构去做的。如果你引入了领域模型，只是在VO，DO，BO，Query等对象之间互相转换，美其名曰项目使用了DDD领域驱动设计，那我劝你再去修炼修炼，形而上的东西没用任何意义。
二、充血模式、贫血模式
关于充血模式还是贫血模式，网络上有很多观点，没有确定答案。楼主找到一篇介绍贫血、充血比较不错的文章可以参考：DDD领域模型和充血对象。这篇文章已经将，贫血模型和充血模型介绍的差不多了，在此楼主提出下自己使用过程中的一些推荐和观点。
关于领域对象中包含数据库操作的充血对象，暂时使用的人还很少，作者也不喜欢这种做法。下面就说一下贫血模型中使用的建议。
- 贫血模型不是只做对象转换：
很多人使用贫血模型，只是把对象从Param转为DO，DO转为VO这样，就结束了，没有任何意义。 - param中做入参校验：在param中应该对数据库的增加或者修改分别作参数校验。
@Data
public class BloodPressureReportParam {
private Long id;
private String interpreteData;
}
如果Param中只有get，set那是谈不上领域模型的，没有起到领域内的作用，我们知道param是传入的参数，如果加上入参的验证方法：
@Data
public class BloodPressureReportParam {
private Long id;
private String interpreteData;
public void valideInsert() {
if (StringUtils.isBlank(interpreteData)) {
throw new ParameterNotValidException();
}
}
}
就能体现领域内的含义了。
- vo可以对展现层的细节作出转换：
都会做的是加一些展示层的字段，如果再添加一些展示层的字段转换逻辑方法，就更合适了。
如下举例，职称id与职称名称是一一对应的，比如1是警官，2是警司，这个时候VO中就可以如下展示：通过id设置名称。
ublic class BloodPressureReportVO {
/**
* 职称
*/
private Byte professionTitle;
/**
* 职称名称
*/
private String professionTitleName;
public void setProfessionTitle(byte title) {
this.professionTitle = title;
String tName = Title.gettNameByT(title);
this.professionTitleName = professionTitleName;
}
public enum Title {
SIR((byte)1, "警官"),
SIRF((byte)2,"警司");
private Byte t;
private String tName;
Title(Byte t, String tName) {
this.t = t;
this.tName = tName;
}
public static String gettNameByT(byte t) {
Title[] values = Title.values();
for (Title title : values) {
if (title.t.equals(t)) {
return title.tName;
}
}
return null;
}
}
}
本篇先介绍的DDD的基础，起码会了这些你的领域模型不再是类型间的互相转换了，老铁，但是距离DDD还有很长的路要走，需要掌握的话，请关注后续文章。
