アタッチメント管理

Question

Meetingに0以上の数字を持つシステムを構築しています。Attachmentです。 Meetingをロードするたびに添付ファイルバイナリ全体を読み込まないようにするには、AttachmentRef(size, mimetype, reference, name, hash)があります。 AttachmentsFactory.create(name, byte[]):AttachmentRef：このリファレンスはmimetypeを推測する工場を経て作成され

、hashとsizeとすべてはさておき、バイナリコンテンツの保存されていることesnureを計算します。

次に、ユーザーが添付ファイルを取得する場合、参照を逆参照する必要があります。 Attachmentは、バイナリの内容がAttachment(size, mimetype, name, content)（参照とバイト[]のコンポジションで実装されています）という点を除けば、リファレンスとほぼ同じです。

私の質問は、この添付ファイルの検索についてですが、私は2つの主要な可能性を持っており、「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) 

Answer 1

これは実際に有界コンテキストの間の相互作用のかなり良い例です。 。あなたが参照して行っているよう

あなたMeetingは1つのBCであり、あなたのコンテンツがContent BCであるならば、あなたは非常によく、物理的に接続コンテンツ（byte[]）を持っている可能性は、あなたのMeetingに値オブジェクトとして表現しました。

添付のコンテンツがあなたのContent BCで、それは集約ルートだろうという点でContentItemまたはいくつかのように表すことができます。

実際のコンテンツの取得は、通常、統合/アプリケーション層で行われます。 Meeting紀元前にそれほど多くないとは思いません。