彼の本の中でエリックはモジュールの主題にほとんど触れていません。彼はまた、モジュールの構造と制限されたコンテキストとの関係についても例を挙げて話していません。バウンドコンテキストにはモジュールが含まれていますか、それともモジュールにはバウンドコンテキストが含まれていますか?アプリケーションにDDDがある場合、どのくらい簡単に拡張できますか?
Extensibleアプリケーションを設計する場合、アプリケーションの構造は非常に重要です。Microsoft MEFフレームワークは、dllからモジュール/コンポーネントを自動検出できます。
例を見てみましょう。eコマースアプリケーションでは、支払い処理のコンテキストを制限することができます。支払い処理は抽象的である可能性があるため、後でPaypalやPayflowなどのより多くの支払い処理業者でアプリを拡張できます。現在、私はPaypalしか持っていませんが、数か月後にPayflowを統合したいと思っています。Payflowを統合するために、支払い処理のインターフェイスを実装するアセンブリ(dll)を作成できます。そのdllをアプリケーションにドロップすると、MEFが自動的に検出します。
ここでの課題は、PayFlow支払い処理用に作成されたdllがモジュールであり、Bounded Context(BC)ではないことです。BCとして作成した場合、支払い処理用に2つのBCがあります。(Paypal用に作成されたBCとPayflow用に作成されたBC)。境界コンテキスト内のモジュールとアセンブリ(dll)としての境界コンテキストを使用してアプリケーションを構造化する場合、モジュールはアセンブリではなくフォルダーとしてBCに存在できます(Visual Studioで作成されたC#ライブラリと考えることができます)。
DDDでこの拡張性の問題をどのように処理できますか?支払い処理、BC、およびその下にあるモジュールとしてのさまざまなフォルダー、Paypal用のものなど...または別のBC内にサブBCが必要ですか?