福勒的书
Refactoring将“数据类”列为代码气味.然而,当单元测试方法时,传递价值对象,例如数据传输对象,使测试比尝试设置或检查类中的状态容易得多.
它引起了我的注意,测试驱动开发方法依赖于这样的想法：易于编写的测试表明界面清洁,方法是一致的.纯粹的幂等方法是最容易测试的,最简单的重用.那么为什么一个数据类是坏事呢？推荐的修复是将行为移动到数据类中,但是为什么值对象需要行为？
我不认为数据类与值对象相同.价值对象通常是不变的,如长度或金钱.福勒所指的“数据类”看起来像贫血域模型 – 即吸烟者和杀手的袋子.
因此,将值对象传递给方法,但绝对不是贫血域模型是可以的.那是因为这种方法会对多种事物产生不利影响,而且很可能违反了单一的责任模式.
不可修改的数据类的情况：
在这种情况下,我建议有一个映射器层将共享实体映射到富域模型,反之亦然.您的代码将主要处理丰富的域名模型.这个想法不是用太多的业务逻辑来过度负担服务类,因为这对代码重用和可测试性是不利的.当然,设计更是一种艺术 – 而不仅仅是黑色和白色.如你所说,数据类是DTO或共享的不可修改的实体不可或缺的.但是,一个强大的域驱动设计可以节省时间地使用这些设计,并尽可能减少代码库的脚印.
