ディレクトリ構造内でコンテキストを明示的にする

Question

アプリケーションの特定のディレクトリ構造に関するフィードバックを探しています。私はこれが "正しい答え"のようなものがある古典的なスタックオーバーフローフォーマットには従わないが、それでも面白いと思うが、意味のあるフィードバックを提供するには、最初にいくつかの文脈を理解する必要がありますので、私にご負担ください。

-

私の2人の同僚と私はClean Architectureを使用するアプリケーションを作成しました。ルートへのHTTPリクエストは、リクエストモデルに変換され、ユースケースに渡され、プレゼンターに渡されるレスポンスモデルが吐き出されます。

コードは完全にオープンソースで、on GitHubがあります。メインディレクトリの内容についてはsome docsも記載しています。

私たちはコードを再編成することを考えており、私たちがこれまでに思い付いたことについてフィードバックを得たいと考えています。主にこの再編の理由の中で、次のとおりです。

• 今私たちは、ドメインの一部ではないものを入れるのに良い場所を持っていない、まだ何とかそれに特異的に結合します。例えば、寄付IDについて知っている認可コード（寄付IDは、認可がコアドメインの一部ではない）。

• 結束性のあるものをまとめてグループ化するとよいです。私たちの寄付コードは結束しており、メンバーシップアプリケーションコードは結束していますが、お互いに依存しません。これは、ドメイン駆動型設計における束縛されたコンテキストの概念と密接に関連しています。現在のところ、これらのコンテキストはコードでは明示的には表示されないため、特にドメインに精通していない場合は、それらを互いに依存させるのは簡単です。

これらはこれまでに特定したコンテキストです。これは暫定的なリストであり、あなたにアイデアを提供するだけであり、フィードバックが必要な部分ではありません。

• 寄付
• 会員
• フォームのサポートスタッフ（電子メールの検証、IBANの世代、など）

私は上のフィードバックをしたい部分は、私たちがへの切り替えを考えるディレクトリ構造であります：

src/ 
    Context_1/ 
     DataAccess/ 
     Domain/ 
      Model/ 
      Repositories/ 
     UseCases/ 
     Validation/ 
     Presentation/ 
     Authorization/ 
    Context_2/ 
    Factories/ 
    Infrastructure/ 

tests/ 
    Context_1/ 
     Unit/ 
     Integration/ 
     EdgeToEdge/ 
     System/ 
     TestDoubles/ 
    Context_2/ 

Authorization/フォルダは、コンテキストのすぐ内側にあります現在インフラストラクチャに奇妙に配置された認証コード。私たちのドメインに属していない他のコードは、それにバインドされていてもコンテクストフォルダに直接行くことができ、承認のような密接な/関連する束があれば独自のフォルダを取得します。

有用なフィードバックを提供するために必要な追加情報を提供しています。

Answer 1

私たちは、ドメインの一部ではないものの、まだ何らかの形でそれに結びついているものを置くのに適していません。

今のところ、これらのコンテキストはコード内に明示的には表示されないため、特にドメインに精通していない場合は、それらを互いに依存させるのは簡単です。

この問題に対処するための技術的および非技術の両方の方法があります。

• あなたはクラスライブラリを通じて厳格な分離を強制することができます。別のプロジェクトのdll/referenceをインポートする必要がある場合は、何かに依存していることがより明白です。また、循環依存性を防止します。
• コードレビュー/規律は、それを処理する非技術的な方法です。

Hexagonal Architectureは、ドメインが中間にあるDDDに使用されています。リポジトリなどのその他の問題は、インタフェースによって表されます。アダプターはドメインへの参照を受け取りますが、他の方向への参照は行いません。あなたのドメインにIRepositoryがあるかもしれませんが、あなたのWhateverDatabaseRepositoryはそれ自身のプロジェクトです。ユース・ケースを調整してアダプターをロードするのは、アプリケーション・サービス/コマンド・ハンドラーの役割です。これは、認可などのクロスカッティングの問題を適用する場所です。

グレッグ・ヤングの動画（試してみるとthis one）とVaughn Vernon's IDDDと読むことをおすすめします。あなたのようなアプリケーションを構成し、質問を扱う方法がわかります。一例として、

、参照（私の答えは基本的に6HRビデオを見て、600以上のページの本を読んで、彼らの両方が本当に私のためにDDDのより多くの「ふんわり」な側面のいくつかを明確に助けていることを申し訳ありません）https://github.com/gregoryyoung/m-r/blob/master/SimpleCQRS/CommandHandlers.cs