モジュラーサービスアプリケーションの設計


11

本質的に非常にモジュール化された新しいソリューションの設計を検討しており、その設計をサポートする構造を作成して、将来の拡張、懸念の明確な分離、モジュールごとのライセンス付与などを可能にします。 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システムで多くの作業をしており、このタイプのモジュール方式で設計されていることを知っているため、この例を意図的に使用しました-方法がわかりません。また、上記では明示的に言及していませんが、ドメインドリブンデザインの原則に従ってソリューションを設計し、このタイプのモジュール性がその領域にぴったりと収まると考えています。

私の頭をこれに巻き付ける助けは大歓迎です。


1
ごめんなさい。すべての思考の中で質問を見つけることができません。質問はなんですか?
-S.ロット

1
疑問符を探します。私はオプションを提供しますが、正しい道にプロセスを導くのに役立つ解決策といくつかの特定の質問を想定しないいくつかのポイントがあります。
-SonOfPirate

1
@SonOfPirate:ごめんなさい。他の人々があなたを助けることができるように、質問を強調したり強調したりするのに時間をかけることを望んでいました。
-S.ロット

4
S.Lottに同意します。申し訳ありませんが、これは質問ではなく、意識の流れです。これを1つまたは2つの焦点を絞った質問に要約し、アーキテクチャの懸念事項を実装の詳細から分離しようとする場合、私たちはあなたをよりよく助けることができます。
アーロンノート

1
@SonOfPirate:「アーキテクチャ」とは、構造と、その構造を他の開発者に伝えることです。説明で始まります。他の開発者がそれを完全に「取得」し、彼らが行うすべてのことにおいてアーキテクチャ設計の原則に従うことができるレベルの明快さと透明性を達成する必要があります。
S.Lott

回答:


2

各モジュールが、そのモジュールのニーズに合うように設計されたインベントリアイテムの独自のバージョンを持つことは理にかなっていますか?その場合、GoodsReceivedEventを処理するときに、Financialモジュールは在庫アイテムの独自のルックアップを実行する必要があります。モジュール性と情報を共有する必要性との境界線はどこにありますか?

常にトレードオフを受け入れる必要があります。あなたの質問に本当に言えることはこれだけです。エンティティを別のアセンブリに保持することは良い習慣であるため、多くのアプリケーションはエンティティを共有ライブラリに保持します。しかし、それは(物理的な)ビジネス論理的な境界がないことを意味します。独自のルックアップを実行すると、両方のモジュールに特別な要件がある場合にのみ実装する冗長なコードが大量に必要になります。もちろん、アーキテクチャの観点から見ると、金融モジュールと在庫モジュールはいずれにしても依存関係を共有する必要があります。金融モジュールは、おそらく在庫モジュールに依存しています。要件により、あるモジュールを別のモジュールに依存させることが許可されている場合、エンティティが最も属しているモジュール内にエンティティをカプセル化してもかまいません。君は' 物理的な区別(共有された依存関係)とメンテナンスとの適切なバランスを見つける必要があります。共有依存関係が多すぎると、バージョンのメンテナンスの悪夢が生じる可能性があります。また、ORMでは、新しいリレーションを既存のエンティティにマッピングしたり、エンティティを含むモジュールに依存するモジュールから拡張したりする場合に問題が発生します。

ORMを使用しない場合、すべてのモジュールはおそらく同じデータベースを共有する可能性が高いことに留意してください。それを共通の基盤として使用できます。

また、データを(CSV /結果セットなどの観点から)維持し、中央メッセージングサービスを使用して、それに登録されたモジュールに新しいデータといくつかのメタ情報を通知することもできます。つまり、実際の依存関係はありませんが、型の安全性と契約を犠牲にし、不正な形式のデータで問題が発生する可能性があります。私はそれが何個の大きなERPシステムがそれを行うかを推測します。

要するに、どの種類のインターフェイスを使用するかを決める必要があります。モジュール性が高いほど契約が少なくなり、逆もまた同様です。

おそらく、データオブジェクトに共有ライブラリを使用し、サブスクライブパブリッシュパターンを持つ中央メッセージングサービスを使用するのが、これが私にとって最良のソリューションだと思われます。


また、これに同意します-メッセージング+ pub / subおよびdto契約の共有ライブラリ(内部nugetリポジトリ)。この記事は私のための視点に入れてまで、私は@SonOfPirateと同じ質問に思っていた:msdn.microsoft.com/en-us/library/bb245678.aspx
diegohb
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.