用例作为OOP中的对象

Question

在当前项目中，我们尝试将用例实现为对象，例如：

public class SaveSalesOrderUseCase {
    public void Execute(SalesOrderUseCaseModel salesOrderModel) {
       // implementation as list steps defined in use-case
    }
}

以这种方式设计系统是否有意义？如何（正面和负面）影响系统的设计，包括OOP，SOLID原则和领域模型等？

有经验吗？

谢谢。

Answer 1

用例并非旨在反映系统的结构，而是反映其行为。

  

以这种方式设计系统是否有意义？

不是，需求经常变化。 这可能导致课程不再反映其意图。

  

如何（正面和负面）影响系统的设计   关于OOP，SOLID原则和领域模型等问题？

从OOP的角度来看，这没有任何意义。

用例标题旨在描述良性解决的整个问题。 这将导致类名不反映单一责任。

这会导致各种设计缺陷（特别是在阅读中）。

Answer 2

这种方法可能会引入重复的代码，并且一个用例可以跨越不同的域区域，在这些区域中您可能会发现难以维护代码。 来到OOP，我觉得这是一个偏差，因为用例不是真正的对象。 这种方法可能会让您觉得您基于SOLID原则，但我觉得并不是因为您的用例可以跨越域之间的情况，saveOrder可能会触及Customer域和Inventory以及一些财务，每个都有自己的SOLID类和你应该有Facade类saveOrder来使用它们。

Answer 3

如果您想“工业化”用例的执行，例如处理队列或批量处理，您可能会这样做。但是，一个用例与人类用户采取的手动操作密切相关，我看不出多少用途。

另一个原因可能是你想要定义一般用例的操作：undo / redo，record execution等。

然而，您的用例可能必须继承一个公共基类。

否则，我会说KISS / YAGNI适用，而且有点矫枉过正。

Answer 4

我认为这样做是完全可以接受的。有一种称为DCI (Data, context and interaction的架构模式，其中一个用例在上下文中实现，域对象在该上下文中起到了一定的作用。

其中一个原因是系统的行为不应该分散在您的应用程序中。这可能会让人难以理解发生了什么。

DCI并不比其他架构更好或更差，它只是一个你可以选择的选项。