設計方法（域驅動或服務驅動）

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。

但同樣，在不知道你的最終目標的情況下，很難說。