我们的团队对 DDD 还很陌生，并且正在尝试在我们当前的项目中实施一些概念。出现的一个问题是是将方法放入实体对象还是服务对象。
一些团队成员认为实体应该只保存值，所有功能都应该包含在服务中。其他人认为这会使实体对象变得贫乏，他们应该拥有与实体相关的功能，而服务对象应该用于更多的横切功能。
我们想知道 DDD 的正式观点是什么，以及在现实生活中什么对人们有用。
【问题讨论】：
标签： design-patterns oop dns domain-driven-design
我们通常非常擅长为所有事情提供示例，但在 DDD 架构方面，每个工程师似乎都是一位理论物理学家，并且在没有一段代码作为示例的情况下撰写有关该主题的文章。
【讨论】：
根据Domain Driven Design Quickly，对象分为三种基本类型。
应用程序的业务逻辑在所有这三个对象中实现，但我们要谨慎地划分逻辑。
服务可以对服务于实体和值对象的相关功能进行分组。明确声明服务要好得多，因为它在域中创建了一个明确的区别：它封装了一个概念。将此类功能合并到实体或值对象中会造成混乱，因为不清楚这些对象代表什么。
另一方面，
服务不应替换通常属于域对象的操作。我们不应该为每个需要的操作创建一个服务。但是当这样的操作在领域中作为一个重要概念脱颖而出时，应该为它创建一个服务。服务具有三个特征：
- Service 执行的操作是指一个领域概念，它自然不属于实体或值对象。
- 执行的操作引用域中的其他对象。
- 操作是无状态的。
因此，有一些明确的标准可以确定方法所属的位置。不幸的是，DDD 并不是说业务逻辑属于实体或业务逻辑属于服务那么简单。这两种说法都不正确。答案是两者兼而有之。
最后，不要为了避免贫血的领域模型而向领域对象添加方法。
当我们创建软件应用程序时，应用程序的很大一部分与领域没有直接关系，而是基础设施的一部分或服务于软件本身。与其他应用程序相比，应用程序的域部分可能非常小，这是可以接受的，因为典型的应用程序包含大量与数据库访问、文件或网络访问、用户界面等相关的代码。
【讨论】：
DDD 没有正式的观点，但丰富的域模型的全部目的是避免Anemic Domain Model，因此明确拒绝将任何行为放在域对象上违背了它的精神。
一个学派认为域对象应该是 POCO/POJO，这意味着它们不应该包含抽象服务作为成员。但是，这并不意味着他们不能拥有与此类服务交互的方法。
您可以为每个域对象提供越多（相关的）行为越好。
【讨论】：