新的一节课程中我产生的问题是：数据库表里的字段是ruleModels（这是一个varchar,里面用符号分割类各种模型，其中就有”rule_weight“）为什么要Entity里写getRuleWeight，然后Service里面判断是否是rule_weight? 我之前写mvc的crud时，更多的是entity把数据给到service，service自己一通操作后进行判别？ 所以我很疑惑，为什么ddd中这样写， 比如mvc里我会这样写
if (strategy.getRuleModels().contains("rule_weight")) {
...
}
ddd却是这样写
if (strategyEntity.getRuleWeight() != null) {
...
}
在我问ai后，我得到了一些概念:
1.Tell, Don’t Ask（告诉对象做事，而不是问它的数据再自己处理）。
2.贫血模型（Anemic Model） ： 对象只有数据，没有灵魂。
充血模型（Rich / Domain Model） ： 对象既有数据，也有行为。
这样做，确实责任划分地更加清楚了，逻辑更加清晰，但是我其实还有些懵，于是我问，好处是什么？
代码更像业务语言、变化集中、Service 不膨胀、规则不分散、扩展能力更强，同时领域逻辑可以脱离技术环境独立测试。
我感觉通过这点，我更好地体会到了什么是ddd的解耦。如果不去想之前我写的mvc，我读代码会感觉非常自然，想知道这个抽奖策略下到底包不包括ruleWeight，我只要用strategyEntity去getRuleWeight,获得了就是有，没获得就是没有，这太自然了，有一种很奇妙的感觉，写的时候感觉绕来绕去，但是读的时候，却是这种感觉。DDD 并不是为了让代码更复杂，而是为了让代码更像业务本身。写的时候可能多走两步，但读的时候，却像在读一段业务说明书。 在传统 MVC 中，Entity 往往只是数据载体，业务判断大量堆积在 Service 中，对象“有名无实”，这就是所谓的贫血模型。
在 DDD 中，更推荐使用充血模型：领域对象不仅保存数据，还承载与自身状态相关的业务行为。Service 不再关心字段细节，而是通过 Tell, Don’t Ask 的方式驱动对象完成业务。
而且我感觉对面向对象有了更好的理解，之前我一直没感觉面向对象和面向过程有什么太多的区别，我感觉java就是把C语言的过程封在了类里。现在我感觉，责任划分就是面向对象的精髓，什么类干什么事，这就是面向对象，责任划分不好，用的面向对象的语言写出来的也不是面向对象。
