2016-05-10 5 views
3

Webアプリケーションのサーバー側コードのドメイン駆動型設計を遵守しようとしています。このアプリケーションでは、ユーザーはファイルをアップロードしてから処理することができます。ユーザーは元のファイル、プロセスのログファイル、またはエラーが記録されたファイルをダウンロードできます。ファイルを含むドメインモデルのファイルストレージはどこに実装しますか

私はFileNameプロパティを持つimportというドメインモデルを持っています。そのファイルが物理的に存在する場所は、ユーザーIDなど、つまり動的に構築されたフォルダ構造に依存します。

明らかに、ドメインモデルはインフラストラクチャなのでファイルストレージについて知ってはいけません。そのため、インポートドメインモデルをとり、さまざまなファイルを取得するインフラストラクチャサービスを作成することを考えています。

これはファイルストレージをドメインモデルから分離しますが、ドメインモデルにそのファイルを要求することを防ぎます。つまり、インポートドメインモデルにエラーファイルまたはオリジナルファイルを与えるように頼んだりできます。

インフラストラクチャサービスを使用するのに間違いがないか、ドメインモデルを使用するより良い方法があります。つまり、ファイルの読み込みなどを処理するクラスに注入するか、これをより正確に行う方法です?

よろしく、 ゲイリー

+0

問題のスペースが大きい画像はここにありません。あなたのコアビジネスドメインは本当にファイルですか?はいの場合、どうですか?そうでない場合は、典型的なコアドメインオブジェクトは機能的にファイルに関連していますか? – guillaume31

+0

私たちのコアビジネスドメインはファイルについてではありませんが、私たちはコアドメインをより小さな境界のあるコンテキストに細分化しようとしています。境界が狭いコンテキストの1つは、データのインポートです。 Entity Frameworkを使用してデータベースから詳細を取得しますが、実際のファイル自体はローカルサーバー上またはクラウド上に配置できます。 ユーザーは、データのインポートを表示し、インポートごとに存在するファイルをダウンロードできます。現在、System.IOで動作するクラスで渡すドメインモデルにパラメータ注入を使用することを考えています。 –

+1

私は本当にBounded Contextsを念頭に置いていました:)その特定のBCのDDD戦術パターンを使用したいと思いますか?それはあなたのコアドメインではない、多分あなたはこれのためにCRUDishの解決策を思いつく時間と労力を節約するのに費やすだろう。それは、とにかく豊かなドメインモデルのそれほどではありません。 – guillaume31

答えて

1

あなた自身がドメインの一部であるファイルではなく、ストレージの仕様についての知識が必要な場合は、適切なアプローチは、依存性逆転の原則のようになります。

を定義しますインポートドメインオブジェクトを指定してファイルを返すことができるドメインサービスインターフェイスです。ファイルが集約の一部であるように、つまりフリーフローにならないように集約を設計するようにしてください。

インフラストラクチャレイヤにそのインターフェイスを実装し、そこにすべてのストレージロジックを配置することができます。 DIメカニズムを使用して実装をインターフェイスに配線します。

+0

これは私が行くことを終えた方法です、それは素敵で清潔であり、それはうまくいくのですか?回答ありがとうございます。 –

関連する問題