モジュラーサービスアプリケーションの設計
本質的に非常にモジュール化された新しいソリューションの設計を検討しており、その設計をサポートする構造を作成して、将来の拡張、懸念の明確な分離、モジュールごとのライセンス付与などを可能にします。 Webで発見されたモジュラーアプリケーションまたは複合アプリケーションはUI中心で、Silverlight、WPFなどに焦点を当てています。私の場合は、さまざまなUIプロジェクトに取り組んでいる他の開発者が使用するWCFサービスアプリケーションを開発しています。 バックグラウンド 私のプロジェクトの目標は、ビジネス/ドメインロジックの一元化されたソースを作成して、現在プロセスやルールなどを複製しているいくつかのビジネスアプリケーションをサポートすることです。また、モジュール性のすべての利点が得られるわけではありませんが、活用できるこれらの部分を活用するフレームワークを確立する機会。 サービスアプリケーションによって公開されるAPIを見て、設計を開始しました。私が検討していたモジュラー回線に沿ってサービスを分離できることは明らかです。たとえば、FinanceService、InventoryService、PersonnelServiceなどのサービスを使用して、サービス操作をグループ化して、APIで高い凝集度を提供し、カップリングを低く抑えて、クライアントがアプリケーションに関連するサービスのみを消費するようにします。 MyApp.Finance、MyApp.Inventory、My.Personnelなど、これらのサービスごとに個別のモジュールを持つことができるのは理にかなっています。横断的関心事と共有タイプは、MyApp共有アセンブリにあります。ここから少し縛られます。 （ああ、アプリケーションの疎結合を維持するためにDependency InjectionにIoCコンテナーを使用することに言及する必要があります。Pandoraのボックスを開きたくないので、どれに言及しません！） MyApp.ServiceHostで、FinanceService.svcなどの各モジュールに対応するサービスホストファイル（.svc）を作成します。サービスホストには、サービスコントラクトを定義するインターフェイスを含む構成ファイルの情報に対応するサービスの名前が必要です。次に、IoC構成を使用して、使用するインターフェイスの具体的な実装をマップします。 1.サービス層はAPIを実装し、モジュールに委任する必要がありますか、またはモジュールは自己完結型である必要があります（サービス実装を含む、そのモジュールに関連するすべてを含むという点で）。 問題にアプローチする1つの方法は、サービスコントラクトの実装を含むMyApp.Services "モジュール"を持つことです。各サービスクラスは、操作のドメインロジックを含む適切なモジュール内の別のクラスに単純に委任します。たとえば、MyApp.ServicesのFinanceService WCFクラスは、Financeモジュールに実装されて操作を実行する別のインターフェイスに委任します。これにより、シンサービスファサードを維持し、実装をサービス実装に「プラグイン」して、たとえばモジュールがWCFを心配する必要がなくなります。 一方で、インターフェイスと実装を備えているという点で、各モジュールが自己完結していることが望ましい場合があります。サービスホストは、モジュールにあるサービスコントラクトインターフェイスを参照し、モジュールからの適切な実装も使用するようにIoCが構成されます。つまり、新しい.svcファイルとIoC構成情報を追加する以外に、サービスレイヤーを変更せずに新しいモジュールを追加できます。 標準のWCFからRESTfulサービスインターフェイスに切り替えるか、RIAサービスなどにアクセスした場合の影響について考えています。各モジュールにサービスコントラクトの実装が含まれている場合、サービステクノロジーまたはアプローチを変更すると、すべてのモジュールに変更を加える必要があります。しかし、ファサードが独自のモジュールである場合、変更するためにその部分を交換するだけです。モジュールは、共有アセンブリで定義されている可能性のある異なるコントラクト（インターフェイス）のセットを実装する必要がありますか？ 2.モジュール間でリソースを共有したり、モジュール間で依存関係を処理する最良の方法は何ですか？ たとえば、受信操作を考えます。商品を受け取ることは在庫機能であるため、最初は赤面でこれが在庫モジュールに入ることは理にかなっています。ただし、領収書を生成して支払いを承認する必要があるという点で、財務的な側面もあります。 一方では、操作を伝えるために何らかのタイプのドメインイベント/メッセージングを使用することを期待します。Inventoryモジュールは、Financialモジュールによって処理されるGoodsReceivedEventを発生させて、領収書を生成し、支払いプロセスを開始します。ただし、これは、金融モジュールが受け取った在庫品目について知る必要があることを意味します。IDで単純に参照できますが、名前や説明、単価など、領収書の追加情報が必要な場合はどうすればよいですか？各モジュールが、そのモジュールのニーズに合うように設計されたインベントリアイテムの独自のバージョンを持つことは理にかなっていますか？その場合、GoodsReceivedEventを処理するときに、Financialモジュールは在庫アイテムの独自のルックアップを実行する必要があります。 ... さまざまなERPシステムで多くの作業をしており、このタイプのモジュール方式で設計されていることを知っているため、この例を意図的に使用しました-方法がわかりません。また、上記では明示的に言及していませんが、ドメインドリブンデザインの原則に従ってソリューションを設計し、このタイプのモジュール性がその領域にぴったりと収まると考えています。 私の頭をこれに巻き付ける助けは大歓迎です。