0

注意 - 所有引述均来自DDD：解决软件核心的复杂性

第一次引用（第 222 页）：

作为域对象的进程

首先让我们同意我们不想让程序成为我们模型的突出方面。对象旨在封装过程，让我们考虑它们的目标或意图。

我所说的是域中存在的过程，我们必须在模型中表示它们。当这些出现时，它们往往会导致尴尬的对象设计。

本章的第一个例子描述了一个运送货物的运输系统。这个路由过程是有商业意义的。服务是明确表达这种过程的一种方式，同时仍然封装了极其复杂的算法。

第二次引用（第 104,106 页）：

有时，它只是不是一件事。在某些情况下，最清晰和最实用的设计包括在概念上不属于任何对象的操作。我们可以遵循问题空间的自然轮廓，并在模型中明确包含服务，而不是强制解决问题。

当域中的重要过程或转换不是实体或值对象的自然责任时，将操作添加到模型中作为声明为服务的独立接口。根据模型的语言定义接口，并确保操作名称是通用语言的一部分。

我不知道在第一次引用中作者是否使用术语“流程”来描述与第二次引用中相同类型的行为（也应该封装在Service中），或者是否使用术语“流程”来描述描述一种与他在第 104、106 页上描述的行为完全不同的行为？

谢谢

4

2 回答 2

2

这些概念非常接近，但对我来说，第一个引用看起来更像是关于在没有软件的情况下存在的大型现实世界域过程（例如“货物路由过程”）。

第二个不太清楚，但我认为它描述了在域的建模版本中发生的较小的操作/流程/转换。

虽然第一种应该从早期分析阶段立即单击“服务”，但后者更微妙，可能需要更多时间才能与常规实体行为区分开来 - 你一开始可以将它包含在一个实体中，但意识到它没有当您改进模型时，t 非常适合它。

于 2013-01-29T09:28:34.677 回答
1

我认为在p。222 他在谈论一种特定的过程。就像在p中一样。102 引用，它们可以作为服务实现。然而，一些过程是指实际的域过程，并且可以从模型中的显式表示中受益。这可能不会立即显而易见，并且可能需要服务之外的更复杂的对象模型。

于 2013-01-29T05:05:21.377 回答