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

【问题标题】：Design approach (Domain driven or Service Driven)设计方法（领域驱动或服务驱动）
【发布时间】：2011-03-25 05:41:43
【问题描述】：

我的问题陈述是：

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

服务驱动方法

写入仅包含文件属性的文件 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.
}

领域驱动方法（这里我可能错了。）

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

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

【问题讨论】：

标签： java architecture domain-driven-design

【解决方案1】：

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

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

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

【讨论】：

【解决方案2】：

没有太多关于您设计的系统类型的信息，很难发音。对我来说，选择取决于系统边界。

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

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

【讨论】：