DDD命名:域对象

Question

考虑某些涉及领域驱动设计(DDD)的对象:实体、值对象、域事件和域服务。

其中哪一个被认为是域对象？还有其他的抽象名称可以封装其中的一个子集吗？

在讨论DDD或域模型时，我可以识别各种有用的抽象：

• Entities和Value对象。我经常提到“实体或值对象”。最值得注意的是，这些是对域状态进行建模的机制。相比之下，域服务是无状态的，我认为域事件仅仅反映了域在其当前的state.
• Entities，值对象和域事件中的信息。--它们都可能包含或表示数据，而域服务只定义域模型所识别的behavior.
• All对象。通常能够讨论域模型的部分内容，而不是它之外的概念。

。

有趣的是，即使堆栈溢出的domain-object标记也有一个令人困惑的定义：

域对象是为处理模型层上的域逻辑而创建的对象。这些对象通常模拟现实生活中的真实(或虚拟)项目:人员、邮政、文档等。

最初的定义侧重于“处理域逻辑”，倾向于“域模型所识别的所有对象”。然后，这些例子倾向于“实体和价值对象”。

DDD锤子的明确定义，明确的无处不在的语言，并有很好的理由。它不应该以身作则吗？:)

Answer 1

，其中哪些被认为是域对象？

他们所有人。它们是实现我们域模型的“对象”。在最初的DDD文本中，Eric Evans还使用了“模型元素”这一短语。

它们之间的区别很大程度上是Java语言约束的结果。如果您只需要创建定制的值，就不需要"value对象“；如果您只需要传递所需的功能，则不需要”域服务“。如果您将“消息传递”作为一个普遍存在的构造，那么您将不需要“域事件”，等等。

的DDD锤子上的明确定义，明确的无处不在的语言，并有充分的理由。它不应该以身作则吗？:)

这个谜团的一部分是，这些模式是通用语言的一部分，DDD的核心信息之一是，您不应该让通用的关注点分散您对域本身的注意力。

上面说..。是的--如果伊万斯在18年前就对这些想法有了丰富的理解，并且能够引进最好的语言，并提供了防止语义扩散的对策，那就更好了。