domain-driven-design - 为什么域服务必须使用域对象作为参数并返回值？

Question

When operation doesn't conceptually belong to any Entity or Value Object, then rather than forcing the behavior into an object, we should create a Domain Service.

The interface of a Service should be defined in terms of other elements of the domain model. In other words, parameters and return values of a Service shold be domain objects

a)为什么/必须域服务将域对象用作参数和返回值？

b)为什么DDD也不要求实体和值对象的方法将域对象用作参数和返回值？为什么相反，此约束仅放在服务上？

谢谢

EULERFX:

1)

Both of these constraints promote immutability and a functional style

a)这两个约束如何促进不变性？

b)什么是功能风格？

c)因此，尽管该服务(即行为)更自然地接受/返回，但我们应该尝试(由于可能并非总是可以使用force)来迫使Service使用域对象作为参数和返回值。非域对象？

2)

Entities and value objects compose more primitive types to form complex types and some behaviors may depend on a primitive parameter.

是不是由于域实体/值对象的某种固有特性而导致它们在大多数情况下的行为(即，它们的操作)在原始类型上运行(即，使用原始类型作为参数)？如果是，那么在大多数情况下，这种固有特征是否在域对象中找到，而在域服务中很少发现？

次更新:

How do the two constraints promote immutability?

这个想法是域服务不会改变状态和所有状态
通过参数明确显示更改。

a)不改变其自身状态或某些域对象的状态？由于域服务应该是无状态的，因此我想您是说它不应该改变DO的状态？换句话说，服务通过确保将要修改的任何DO作为参数传递给它(即，传递给它的操作)来促进不变性？

b)但是，如果不是将要由服务修改的DO作为参数传递，那么我们可以说域服务使该DO的状态发生了变化？

c)之所以将DO的状态改变为坏事，是因为它并没有提高清晰度(即，当查看服务操作的签名时，它不是立即显而易见的，DO的状态将由DO改变)手术 )？

d)如果域服务要修改作为参数传递给它的DO的状态，那么将其用于更改该DO状态的值也作为参数传递给服务是否理想？如果是，是因为它可以提高清晰度还是...？

2)我仍然不明白与参数相同类型的返回值也如何促进不变性？

EULERFX 3

一种)

A domain service can avoid state mutation by returning new instances of objects instead of modifying the objects that were passed in.

并不是每个人都在说一个问题，更多是一个观察，但是在理解为什么这样的服务行为在大多数领域模型中会很常见或者甚至在对领域进行建模时这种行为是否自然产生时还是有些困难，我们还是有些困难？

b)

Yes, although in that case it would be better for the domain object to mutate itself.

DO之所以要进行自身变异的主要原因是，以这种方式对特定DO执行变异的代码集中在一个地方，因此如果我们需要检查该代码，我们知道在哪里寻找它？

Answer 1

a)这不是严格的约束条件，但具有一定的优势。该规则背后的思想是域服务包含补充现有实体和值对象的功能。另一个非严格约束是闭合操作，其中域服务方法的参数和返回值都属于同一类型。这两个约束都促进了不变性和功能风格，从而减少了副作用，并使代码推理，重构代码等更加容易。

可能有一种域服务方法可以接受既不是实体也不是值对象的原始类型。但是，大量使用原始类型可能会导致primitive obsession。

b)此约束可以在一定程度上应用于实体和值(value)对象级别。实体和值对象组成更多的原始类型以形成复杂类型，并且某些行为可能取决于原始参数。这个原始参数本身可以变成一个值对象。

更新

刚从DDD聚会上回来，在那里我有机会与Vaughn Vernon的Implementing Domain-Driven Design讨论了这一点。他同意指定的约束条件不是严格的。换句话说，在某些情况下，可以通过基本类型对域服务方法进行参数化是完全可以接受的。

How do the two constraints promote immutability?

这个想法是域服务不会改变状态，并且所有状态更改都通过参数来明确显示。这是 pure function的本质。鉴于域服务是对实体的补充，它们的方法应以这些术语表示。

What is functional style?

我指的是 functional programming。以功能风格进行编程通常需要不变性和纯功能。功能方法的另一个特征是 declarative style与命令式的对比。

So we should try ( since it may not always be possible to use force ) to force the Service to use domain objects as parameters and return values

不可以。如果基本类型足以完成某个操作，则没有理由将其强制转换为其他类型。实体和值对象的使用仅是一个准则，有些实体比其他实体更严格。例如，有些使用显式类型来表示每个实体的身份。因此，您可以创建一个名为 int的值对象来表示订单的身份，而不是使用 OrderId。

So is it due to some sort of intrinsic characteristic of Domain Entities/Value objects that in most cases their behaviors ( ie their operations ) operate on primitive types ( ie use primitive types as parameters )?

我不会说这是DDD固有的。我指的是更一般的组合概念-复杂实体(非DDD)是由简单实体组成的。通过这种标记，在复杂实体上的操作将用组成部分来表示是有意义的。

更新2

a)域服务可以通过返回对象的新实例而不是修改传入的对象来避免状态突变。通过这种方法，方法签名完全描述了它的作用，因为没有副作用。

b)域服务可以改变传递给它的对象的状态，在这种情况下，返回类型可能已满。但是，这是不太理想的-DO最好改变自己的状态。

c)是的，这是其中的一部分。不变性和纯净性使您可以像重构代数方程一样重构代码。另一个原因是，这使代码的推理更加容易，因为如果您查看一段不可变的数据，则可以确定在其余范围内它不会改变。

d)是的，尽管在这种情况下，最好让领域对象自行突变。这种变异将由周围的应用程序服务调用。很多时候，我将域服务传递给实体行为方法，以提供它们无法直接访问的功能。

e)操作关闭的概念本身并不会促进不变性，但这是不变代码的特征。原因是，如果域服务方法接受类型T的值并返回类型T的值，则它可以指示其返回由封装操作导致的新T值。这是不变性的特征，因为将由操作引起的更改明确地作为新对象。

更新3

a)与DDD相比，它与传统OOP的关系更大。 OOP试图将事件部件隐藏在对象后面-封装。 FP试图将运动部件(不变性)降至最低。在某些情况下，不变性可以被视为更“自然”。例如，在以事件为中心的场景中，事件是不可变的，因为它们记录了发生的事情。您不会更改已发生的事情，但是可以创建补偿操作。

b)同样，这与DOP相比，与OOP的关系更大，并且基于 information expert pattern，它实际上声明数据的行为应尽可能接近该数据。在DDD中，这意味着实体应尽可能封装所包含的数据，以确保其自身的完整性。