最后一点，DDD 中的服务是放置我所说的尴尬"逻辑的地方.如果您有某种类型的逻辑或工作流依赖于其他实体，那么这种逻辑类型通常不适合"域对象本身.示例:如果我的业务对象上有一个方法来执行某种类型的验证，则服务类可能会执行此方法(仍将与实体相关的实际验证逻辑保留在其类中)

To your last point, services in DDD are a place to put what I describe as "awkward" logic. If you have some type of logic or work flow that has dependencies on other entities this is the type of logic that usually doesn't "fit" inside a domain object itself. Example: If I have a method on my business object to perform some type of validation, the service class might execute this method (still keeping the actual validation logic related to the entity inside its class)

我经常提到的另一个非常好的例子是资金转移方法.您不会将帐户对象从一个对象转移到另一个对象，而是拥有一个接受to"帐户和from"帐户的服务.然后在服务内部，您将调用from"帐户上的提款方法和to"帐户上的存款方法.如果您试图将其放入帐户实体本身，那会感觉很尴尬.

Another really good example I always mention is the funds transfer method. You wouldn't have an account object transfer from one object to another, but instead you would have a service that takes the "to" account and the "from" account. Then inside the service you would invoke the withdrawal method on your "from" account and the deposit method on your "to" account. If you tried to put this inside the account entity itself it would feel awkward.

可以找到深入讨论这个主题的很棒的播客 此处.David Laribee 做得非常好，现在只解释了 DDD 的方式"，但解释了为什么".

A great podcast that talks in depth about this very topic can be found here. David Laribee does a really good job explaining now only the "how" but the "why" of DDD.