今儿写这个题目胆子有点大，不过还是得冒险整一篇（我怕您看完了骂我），一是出于经验分享，另外则是为了后面我们讲案例的时候做好铺垫。好的代码需要注意的事项其实挺多的，您真让我一骨脑儿都列出来可能也差点意思，所以遵照我们常态化歪楼的习惯，我是想到哪写到哪儿。
我没事儿的时候就喜欢看别人写的文章，也喜欢看书，收获还是挺多的，不过岁数大了忘性也大，记不住。可有一个事情我记得倍儿清楚：咱们搞技术的尤其是后端开发都知道一类对象叫视图模型（View Object简称VO），一说VO，大多数文章给的概念就是“后端传向前端，用于承载需要在页面上显示的信息的实体或对象（反方向是前端传向后端用于存储的信息）”。概念虽然简单，可是和我的想法就不一样，谁叫咱这人个色呢，您听我给您唠唠。
我所认为的视图相对来说要广义一点：前面您所认为的自然是没问题；还有一种（咱们以Java为例啊）我来举例说明：订单的服务需要调用客户服务来查询客户信息“CustomInfo”，这里面的“CustomInfo”就是视图模型。您肯定暴起反对：搞笑呢吧？“CustomInfo”是“DTO（数据传输对象）”。这种说法当然没错了，但DTO这个说法太广义面且太模糊了。常用的数据实体也算是一种DTO，他承载了需要存储和从数据库查询返回的数据；前端传向后端的也是DTO，承载了用户的输入。所以您平常老是用DTO这个说法其实真的不够准确。那为什么说服务间相互传的数据是VO呢？比如您去相亲，对方给您的印象（注意：印象不仅是你主动获取的，还包括对方传给你的，就跟两个函数一样你调用我我调用你）比如长相、谈吐等这些是对方想让您知道的（别反对，女人画起妆来你就不知道她到底长什么样）关于其自身属性的部分信息，当然还有一部分是您从对方身上获得的信息，所谓的“印象”是两种信息的集成，其实就是信息视图。所以您调用下游服务时对方返回给你的就是这个下游服务的视图也就是下游服务想要展示给你的内容。而且，不仅仅是服务间有视图，包与包之前也只能通过视图了解彼此。
上一段我提到的“服务间和包间只能通过视图了解彼此”，引申的含义是说：服务间和包间只能通过视图传递信息，这种限制不论是3层还是4层构架都适用。DTO这种称呼相对模糊，一般我在开发的时候也不会这么叫。实际上，您是喜欢叫VO还是DTO也不耽误什么事儿，可我们在这里给出了一个重要的约束也就是包或系统间的数据访问限制。这东西特别容易出乱子，尤其是想把一个服务做二次拆分的时候，如果当前系统无访问约束那拆的风险就会相当的高。
除了视图模型外，后端服务开发还会用到另外两类：数据模型和领域模型，如下图所示。您别看统共就三种，想用好了没那么容易。至少在我经历的不少项目中很多人都是乱用的，要不是没有访问限制要不就是模型冗余。
重点！
服务间和包间相互调用时，传入和传出的信息（简单字段除外）只能通过视图模型进行承载，不得将数据模型和领域模型作为传输信息的载体，包括在消息中也不可以内嵌领域与数据模型，以避免内部信息泄露。
对于模型的滥用，让我来厚着脸皮做一下纠偏，分别说一个每个对象的作用和主要的使用限制。看完了后您会觉得：“这也太夸张了，写个代码有那么麻烦吗？”，答：有！好东西一般不会是多快好省出来的。
1、数据模型定义：描述数据库设计并承载数据在持久层到应用层间之间的传输。限制：1）每一张表一个实体；2）级联查询的结果一般是多个表的集成，也需要建立对应的实体；3）不可以传到包、服务之外；4）不要包含任何业务逻辑；5）DAO的输入输出只能是简单字段或数据模型；6）仅能使用基本类型如Integer、String等。有一个小技巧：如果数据模型和视图模型的字段一样，赋值时可以使用一些工具如“BeanUtils”实现两个对象间的字段复制。
2、视图模型定义：用于系统间、模块间、包间传送和展示数据的载体，具体的解释可参考上面内容。限制：1）仅包含最少的用于传输的信息，不要使用一个对象包含所有的字段即万能对象；2）不可以从数据模型继承（这个问题尤其普遍），可使用工具实现与数据模型的互转；3）是包、服务间传输信息的唯一载体；4）不得包含业务逻辑。下面给出了一个“数据字典”视图模型的示例，请参考。
@ApiModel(value = "数据字典信息") public class DictionaryVO extends VOBase { private static final int MAX_VALUE_LENGTH = 32; @ApiModelProperty(value = "字典值，长度：32", required = true) private String value; @Override public ParameterValidationResult validate() { if (this.classId == null) { return ParameterValidationResult.failed(OperationMessages.INVALID_CLASS_ID); } if (StringUtils.isEmpty(this.value) || this.value.length() > MAX_VALUE_LENGTH) { return ParameterValidationResult.failed(String.format(OperationMessages.INVALID_VALUE_LENGTH, MAX_VALUE_LENGTH)); } return super.validate(); } public static DictionaryVO of(DictionaryDataEntity entity) { if (entity == null) { return null; } DictionaryVO vo = new DictionaryVO(); BeanUtils.copyProperties(entity, vo); return vo; } }
上述代码中，视图模型继承于“VOBase”自定义类，此类包含了“validate”方法用于对视图模型中的信息进行验证。切记：前端、其它服务和包传过来的信息永远是不可信的，通过在视图模型中增加验证逻辑可以让代码更简洁。“of”方法用于数据模型和视图模型的转换。“ApiModel”引入了“Swagger”用于对字段进行说明。
3、领域模型定义：描述业务实体属性和行为的模型。一般来说是充血模型，后续会细讲。限制：1）不得依赖于架构中的其它层、第三方基础框架如Spring、DAO、HTTPClinet等。这么说吧，除了JDK外其它都不能依赖。就和狗一样，依赖少表示血统纯粹，越纯粹越好；2）作用范围只能在业务模型层中，不得外泄；3）严格注意每个模型的访问限制，能不用public就不用。4）最好自行写一些包含了公共能力（比如“对象判等”）的领域模型基类来保证代码的干净。
这个里面我觉得有可能争议最大的是关于领域模型的依赖，有一些比如字符串工具、日期工具这种的第三方类库其实很普遍，完全的不依赖是否会更加的极端？怎么说呢，我个人在使用ODD开发的时候写了一套基础组件，包含了验证、值类型、实体类型、领域仓库、Saga等领域模型相关的组件（大部分都是抽象类）和少量的工具类，需要什么拿来即用，我称之为“通用能力库”。这个库本身是自己写的（注：本系列文章只关注DDD知识的讲解，不会推荐任何的、成熟度不够高的尤其是标榜为DDD的框架），也的确没用到JDK外的其它第三方组件。而且，领域模型本身专用于业务逻辑处理和计算，像什么字符串格式化啊、日期格式化啊其实就不应该在领域模型里搞。写通用能力库毕竟也会占用精力，我的推荐是您在领域模型中尽量少的依赖第三方组件，越少越好。有些书籍中会展示在领域模型中注入DAO来实现嵌套对象的“懒加载”，我个人认为这个是不化不类，只有在需要向性能妥协时才会使用。
总结本章讲了三个模型，虽然内容不多，可真正使用起来也是有一定的要求的。软件开发是个细活儿，想做好当然要负出精力了。您完全可以突破上述所提到的限制，也能出东西，可需求总是变化的，总得改代码，到时候吃亏的还是自己。这没办法，坑儿是您自己给自己挖的，除非您写完了代码就打算跑路，那也给了后面接手的人骂爹的机会。另外，您可能认为本章和DDD没关系，我得提前声明：咱不是写小说呢，一个字多少多少钱，这些经验您还真在其它书上找不着。而且，越是细节越能体现开发者的能力，搞技术到后面比的是什么？不再是会什么不会什么了，而是比谁开发的质量高和可维护性高。两个员工做同样的需求尤其是功能增强性相关的，一个5分钟搞定，一个3天，你是老板你用哪个 ？