域中的狀態模式可能會嚴重影響服務層

Question

我們有N層應用程序，我們試圖用DDD來設計。該應用程序作爲REST服務公開。 我們有一個利用狀態模式的域實體。狀態界面是這樣的

interface IDomainObjectState 
{ 
    void SetPassed(); 
    void SetFailed(); 
    void SetIncomplete(); 
    void Pause(); 
    void Block(); 
} 

該實體還具有狀態字段。如果對象的狀態允許，以「Set」開頭的狀態方法應該改變這個字段。雖然這可以讓我們在Domain中擁有相當乾淨的代碼，但它在服務層面很痛苦：我們使用單獨的REST資源來更改實體的狀態（例如，我們使用PUT /result來執行此操作）。這個讓我哭泣的問題是，我們有switch處於DTO中的新狀態，用於選擇這三種方法之一（並且唯一的方法就是在應用層中，我猜）。

將三個「Set *」方法合併爲一個是不錯的主意？如果不是，請提出另一個重構！

Answer 1

將三個「Set *」方法合併爲一個是好主意嗎？

如果唯一的動機是簡化與HTTP接口的集成，這不是一個好主意。國際海事組織，一個開關語句並不可怕，因爲它是適配器/ ACL代碼的一部分，它通常直截了當，易於測試並且不需要很好的設計。理想情況下，HTTP適配器會調用封裝了手頭行爲的應用程序服務。如果你願意，你可以在特定的HTTP資源/動詞組合和應用程序服務方法之間創建一個映射，但是這並不會增加整體的價值。