用例作为OOP中的对象

Question

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

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

用这种方式设计系统有意义吗？在面向对象设计、实体原理和领域模型等方面，它对系统的设计有什么积极和消极的影响？

有什么经验吗？

谢谢。

Answer 1

用例不是为了反映系统的结构，而是为了反映系统的行为。

用这种方式设计系统有意义吗？

不完全是，需求经常发生变化。这可能导致类不再反映它的意图。

在面向对象设计、实体原理和领域模型等方面，它对系统的设计有什么积极和消极的影响？

从面向对象的角度来看，这是没有意义的。

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

这可能导致各种设计缺陷(特别是向下阅读)。

Answer 2

这种方法可能会引入重复的代码，并且有一个用例可以跨越不同的领域，在这些领域中，您会发现维护代码很困难。说到OOP，我觉得这是一种偏差，因为用例并不是真正的对象。这种方法可能会让您基于坚实的原则，但我觉得这并不是因为您的用例可以在不同的领域之间扩展，saveOrder也可以用一些资金来触及客户域和库存，每个类都有自己的实体类，您应该有Facade类saveOrder来使用它们。

Answer 3

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

另一个原因可能是，如果您想通常定义有关用例的操作:撤销/重做、记录执行等等。

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

否则，我会说，接吻/YAGNI适用，这是过火。