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

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.
}

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

Answer 1

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

就面向服务的方法而言，这通常被认为是更高层次的（即面向服务的架构）。 考虑一个金融股票系统，您可能有“买入股票”服务和“卖出股票”服务。 拥有一个对应于各个类的服务类（即一个知道如何买卖股票的股票服务）不会非常面向对象。

您可能还在系统中有一个服务层，它提供与其他外部服务（即数据库）的集成点，但同样，我不认为这就是您在这里所说的。 所以，我可以坚持在File类本身封装逻辑的方法。

Answer 2

如果没有关于你正在设计什么样的系统的信息很多，那么很难发音。 对我而言，选择取决于系统边界。

如果您需要提供作为服务公开且可供外部消费者访问的API，请转到解决方案1，这是唯一的方法。 如果你的系统是一个库，其API将由其他应用程序在内部使用，那么在解决方案2中寻找一个丰富的域模型，它就是更多的OO。 您不希望使用没有真正原因的服务，管理器和实用程序类来扩展您的API。

但同样，在不知道你的最终目标的情况下，很难说。