3

アプリケーションの特定のディレクトリ構造に関するフィードバックを探しています。これは、「正解」などがある古典的なスタック オーバーフロー形式に従っていないことに気付きますが、それでも興味深いと思います。有意義なフィードバックを提供するには、まずいくつかのコンテキストを理解する必要があります。

--

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

コードは完全にオープン ソースであり、GitHubで見つけることができます。また、主要なディレクトリの内容を説明するドキュメントもいくつかあります。

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

  • 今のところ、ドメインの一部ではないものを配置するのに適した場所がありませんが、何らかの形でそれにバインドされています。たとえば、寄付 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/すぐ内側にあるフォルダは、現在インフラストラクチャに配置されている承認コードのホームを提供します。私たちのドメインの一部ではないが、まだそれにバインドされている他のコードは、コンテキスト フォルダーに直接入ることができ、その中にまとまりのある/関連するもの (承認など) がある場合は、独自のフォルダーを取得します。

有益なフィードバックを提供するために必要な追加情報を提供させていただきます。

4

1 に答える 1

4

今のところ、ドメインの一部ではないものを配置するのに適した場所がありませんが、何らかの形でそれにバインドされています。

現在、これらのコンテキストはコードで明示的に表示されていないため、特にドメインに慣れていない場合は、相互に依存させるのは簡単です。

この問題に対処するには、技術的な方法と非技術的な方法の両方があります。

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

ドメインが真ん中にあるDDDでHexagonal Architectureを使用しています。リポジトリなどのその他の問題は、インターフェイスによって表されます。その後、アダプターはドメインへの参照を取得しますが、逆方向には取得しません。したがって、ドメインに IRepository があるかもしれませんが、WhateverDatabaseRepository は独自のプロジェクトにあります。次に、ユースケースを調整してアダプターをロードするのは、アプリケーション サービス/コマンド ハンドラーの役割です。これは、承認などの分野横断的な懸念事項を適用する場所でもあります。

Greg Young のビデオ (これを試してください) を見て、 Vaughn Vernon の IDDDを読むことをお勧めします。アプリケーションを構築する方法や、あなたのような質問に対処する方法が説明されています。（私の答えは基本的に6時間のビデオを見て600ページ以上の本を読むことですが、どちらも私にとってDDDのより「面倒な」側面のいくつかを明確にするのに本当に役立ちました）

例として、https://github.com/gregoryyoung/mr/blob/master/SimpleCQRS/CommandHandlers.csを参照してください。

于 2016-06-26T10:08:26.197 に答える