附件管理

我正在構建一個系統，其中Meeting可以有零個或多個Attachment s。爲避免每次加載Meeting時加載整個附件二進制文件，我有一個AttachmentRef(size, mimetype, reference, name, hash)。通過一個工廠，猜mimetype創建附件管理

此引用，計算hash和size和esnure一切都擱置保存的二進制內容：AttachmentsFactory.create(name, byte[]):AttachmentRef。

然後，當用戶想要檢索附件時，必須對引用進行解引用。 Attachment或多或少與參考文獻相同，除了它具有二進制內容Attachment(size, mimetype, name, content)（但是可以用引用和字節[]）的組合來實現）。

我的問題是關於檢索這個附件，我有兩個主要的可能性，我想知道哪個在DDD設計中看起來最好？

1 - 啞參考，智能服務

AttachementService { 
    dereference(ref):Attachment { 
    // Get the binary, recompute and verify the hash and return an Attachment 
    } 
} 

attachmentService.dereference(ref)

2 - 智能參考，啞服務

AttachmentService { 
    read(ref):byte[] { 
     // Just return the content for the ref 
    } 
} 

AttachmentReference { 
    dereference(attachmentService) { 
     content = attachmentService.read(this) 
     // recompute and verify the hash 
     return new Attachment(this, content) 
    } 
} 

ref.dereference(attachmentService)

來源

2017-10-09 gervais.b

這實際上是相互作用的限界上下文之間一個非常好的例子。

如果您Meeting是在公元前之一，你的內容是在公元前Content，那麼你很可能有物理連接的內容（byte[]）在Meeting表示爲值對象爲您與您的參考實現。

附加的內容可以被表示爲在BC Content一個ContentItem或一些這樣的並且在這將是一個聚合根。

實際內容的檢索通常發生在集成/應用程序層。沒有必要在公元前Meeting有這樣的，因爲它不會做太多，我想。

來源

2017-10-10 05:18:46

好的，謝謝;這或多或少是我想到的。但要返回附件的內容，我必須驗證他的哈希值是否保持不變。這是'AttachmentRef'還是應用層的責任？實際上，它是'AttachmentFactory'計算哈希並構建'AttachmentRef'，但理想情況下算法必須是相同的（代碼），所以我應該把它放在哪裏？ –

我會將該處理放在應用程序/集成層中。當您最初存儲附件時，您需要計算散列並將其與附件關聯。您甚至可能想要爲附件添加一個算法名稱（或稍後在想要更改算法時執行此操作）。然後，當您檢索內容時，比如說，ContentService將注入散列算法（或算法容器）。它然後可以返回來自提取的結果，並且結果可以指示哈希是否匹配;否則拋出一個異常，如果它不匹配，併成爲操作問題。 –

非常感謝Eben –

回答

相關問題