理解OOP，我们就不难理解DDD：
DDD第一原则：将数据和操作结合。（贫血模型将数据和操作分离，违反OOP的原则。）
DDD第二原则：界限上下文。这是将“单一指责”应用于我们的领域模型。

DDD is nothing more than OOP applied to business models. DDD其实就是把OOP应用于业务模型。

实现：
1、使用通用语言（Ubiquitous Language）：类、方法、字段的命名，要符合业务。使用业务语言命名，以后在和客户或者其他团队交流时能够更顺畅。

2、理解系统业务：例如做一个理财系统，要亲自去和银行卖理财产品的人聊聊或者买个理财产品之后，那些数据库中对你来说毫无意义的字段才变得有血有肉。

介绍一篇博客吧：DDD101 https://medium.com/the-coding-matrix/ddd-101-the-5-minute-tour-7a3037cf53b8

最后，是时候祭出大杀器了：《领域驱动设计》Eric Evans （反正我也没看）

看到这里，感觉才真正理解充血模型的作用：

    真正的业务逻辑都放在充血的领域对象中，与具体使用什么框架（比如Spring，MyBatis），具体使用什么数据库无关。这样有利于保护领域对象中的数据，比如钱包中的余额，当有入账和出账操作时，余额在领域对象中自动执行加减操作，而不是将余额暴露在Service中直接操作（这样很容易出错可能导致帐不平衡，余额应该封装保护起来），当然“余额自动增减”这只是一个简单的业务逻辑例子，业务逻辑越复杂就越应该封装到领域对象中。

1. Service层只是一个中间层，起到连接和组合作用。
用于支持领域模型层和Repository层的交互（连接作用），利用各种领域对象执行业务逻辑（组合作用）。
比如通过Repository查出数据，将数据转换为领域模型对象，利用领域模型对象执行业务逻辑（核心），然后调用Repository更新领域模型中的数据。

2. Service类还负责一些非功能性及与三方系统交互的工作。
比如幂等、事务、发邮件、发消息、记录日志、调用其他系统的 RPC 接口等。

    不允许Service中的逻辑过于复杂，如果Service中的组合的业务逻辑过于复杂，我们就要将这业务逻辑抽取出一个新的领域对象进行封装，通过调用这个领域对象来进行这些复杂的操作。

    由于controller和Repository层中本身没有什么业务逻辑，controller中的Vo对象实际上只是传输数据使用（数据从系统传输数据到外部调用方），Repository中的Entity本质上也只是传输数据（数据从数据库中传输数据到系统），所以用贫血模型不会带来副作用，是没有问题的。

看了老师的这篇文章让我对 entity，bo，vo有了一个更清晰的认识。我是这样理解的，entity是对数据库的映射，vo 是前端展示的映射，bo 在 DDD 充血模型中我看到了他的用处，看起来他是将 entity 的一些逻辑业务分离了出来做了一个解耦（在我看来貌似没有 bo 或者说 Domain 类似 加余额减余额的逻辑也可以写在 entity 中，只是这样做对于专注于数据库的 entity 来说逻辑更复杂了，维护起来会很困难 ），同时也解决了 entity 暴露过多 getter setter 方法的问题。不知道我这样理解有没有问题，欢迎老师指正。

同时我有如下几个疑问:
1.具体上 domain 和 entity 属性和结构上有哪些不同呢？（在我看来好像能写成一样的）
2.在贫血模型下 bo 的作用好像没有那么明显了，多写一层 bo 能给我们带来什么好处呢？
3. entity bo vo 类属性上好像有很多重合，貌似在实际编写的过程会出现很多重复代码，并且要为每一层编写转换代码，代码量好像又增加了，对于这种情况应该怎么优化和权衡呢？

感谢老师的分享，收获很多，也产生了两个问题：

问题1：Entity 转换成 Domain 的代码应该在哪一层实现？感觉在 Service 层不大合适，因为可能多个 Service 会使用到。
问题2：如果涉及到表单的保存，入参是一个保存全量数据的对象(比如，创建一个新用户的所有用户数据，但部分属性还是要计算得到的，比如年龄等)。这个对象是属于 VO 吗？这时的 Domain 怎么设计呢？数据模型间的转换怎么处理呢？VO->BO->Entity 感觉就是在写各种赋值语句啊, 所以我以前在传统开发模式是合并 VO、BO、Entity的，一个大而全的东西也是很尴尬。

期待老师解答。