设计方法论（领域驱动或服务驱动）

Question

我的问题陈述是：

我想编写设计文件管理（添加、复制、删除等操作）。有两种方法：

1. 服务驱动方法

编写仅包含文件属性的文件VO。例如：

public Class File {
    private boolean hidden;
    private boolean read;
    private boolean write;

    public boolean isHidden() {
        return hidden;
    }
    public void setHidden(boolean hidden) {
        this.hidden = hidden;
    }
    public boolean isRead() {
        return read;
    }
    public void setRead(boolean read) {
        this.read = read;
    }
    public boolean isWrite() {
        return write;
    }
    public void setWrite(boolean write) {
        this.write = write;
    }
}

并为文件相关操作提供了分离的服务。例如：

public Class FileService {
        public boolean deleteFile(File file) {
            //Add delete logic.
        }
        //Same way you can add methods for Add and copy file.
}

2. 领域驱动设计（我的理解可能有误）

其中文件VO包含所有属性及所需操作：

public class File {
    private boolean hidden;
    private boolean read;
    private boolean write;

    public boolean isHidden() {
        return hidden;
    }
    public void setHidden(boolean hidden) {
        this.hidden = hidden;
    }
    public boolean isRead() {
        return read;
    }
    public void setRead(boolean read) {
        this.read = read;
    }
    public boolean isWrite() {
        return write;
    }
    public void setWrite(boolean write) {
        this.write = write;
    }
        public boolean deleteFile() {
            //Add delete logic.
        }
        //Same way you can add methods for Add and copy file.
}

那么这两种方法的优缺点是什么呢？

- Silent Warrior

Answer 1

在面向对象的语言中，将逻辑放在类本身而不是服务类中是典型的方法（在我看来更好）。它遵循“告诉，不要询问”的原则，例如，通过告诉文件删除自身，而不是请求某个服务删除它。这背后的主要原因之一是为了允许继承。例如，如果您有一个 File 的子类并希望在它被删除之前写入日志消息，则使用服务类会很困难，因为您需要为每个子类使用不同的服务类。

在面向服务的方法方面，这通常是在更高层次上考虑的（即面向服务的架构）。考虑一个金融股票系统，您可能会有“购买股票”服务和“出售股票”服务。拥有与各个类相对应的服务类（即知道如何购买和销售股票的股票服务）不会非常面向对象。

您还可以在系统中拥有服务层，该层提供与其他外部服务（例如数据库）的集成点，但我认为这不是您在这里谈论的内容。因此，我可以坚持将逻辑封装在 File 类本身中的方法。

- Jeff Storey

Answer 2

没有太多关于你正在设计什么样的系统的信息，所以很难下结论。对我而言，选择取决于系统边界。

如果您需要提供一个作为服务公开并可供外部使用者访问的API，请选择方案1，那是唯一的方法。如果您的系统更像是一个库，其API将由其他应用程序在内部使用，请选择解决方案2中的丰富领域模型，它更加面向对象。您不想用服务、管理和实用类膨胀您的API，这些类没有真正存在的原因。

但是再次强调，如果不知道您的最终目标，很难下定论。

- ewernli