用例作为OOP中的对象

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

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

这样设计系统有意义吗？它如何（正面和负面）影响OOP、实体原则和领域模型等方面的系统设计

有经验吗

---

谢谢。

这种方法可能会引入重复的代码，并且一个用例可能会跨越不同的领域，您可能会发现维护代码的困难。 谈到OOP，我觉得这是一种偏差，因为用例不是真正的对象。

---

这种方法可能会让你觉得它是基于可靠原则的，但我觉得它不是你的用例可以跨域的，在你的情况下，saveOrder可能会涉及到客户域和库存以及一些财务，每个都有自己的可靠类，你应该有Facade类saveOrder来使用它们

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

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

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

---

否则，我会说KISS/YAGNI适用，这太过分了。

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

这样设计系统有意义吗

事实并非如此，需求经常变化。 这可能导致类不再反映其意图

它如何（正面和负面）影响系统的设计 关于OOP、实体原理和领域模型等方面

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

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

---

这会导致各种各样的设计缺陷（尤其是在底层）。我认为这样做完全可以接受。有一种架构模式，称为在上下文中实现用例，域对象在该上下文中扮演特定角色来实现场景

其中一个原因是系统的行为不应该分散在应用程序中。这会使人难以理解正在发生的事情

---

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

DCI肯定比传统OO“更好”，因为它的目标是缓解在该范例中发现的问题。如果您将系统行为视为第一类公民，封装该行为的类将承担单一责任。这就是DCI做得很好的地方。