非常に緩い結合を実現するための最良の方法は何ですか?
システム内の他の部分に依存している部分がないようにソフトウェアを極端にモジュール化したいが、それでも通信できる場合は、この目標を達成するために(テクノロジーにとらわれない)使用する必要があります。
提案をお願いします、これをブレインストーミングと考えてください... :)
非常に緩い結合を実現するための最良の方法は何ですか?
システム内の他の部分に依存している部分がないようにソフトウェアを極端にモジュール化したいが、それでも通信できる場合は、この目標を達成するために(テクノロジーにとらわれない)使用する必要があります。
提案をお願いします、これをブレインストーミングと考えてください... :)
ドメイン分離データ形式を使用して、XML、RPC、HTTPなどのモジュール間の通信または情報交換を可能にします。
さまざまなチームが互いに話し合ったり、取り組みを調整したりせずに、さまざまなモジュールを開発できるようにします。後でさまざまな役割のさまざまなシステムで使用される一般的なインターフェイスを備えた統合モジュールを設計するという目標を設定します(もちろん、モジュールの機能範囲内で)。
データ。
ゆるく結合したい場合、答えはデータです。プログラムまたはコンポーネントは、相互に「機能を実行」することはなく、相互にデータを渡します。(内部的には、これはおそらくメソッドを呼び出すことによって行われますが、メカニズムは別として、概念的にはデータを渡す必要があります)。
プロセス内のデータが不変として扱われる場合は、さらに優れています。
これにより、コンポーネントの境界が明確になり、変更が爆発するのを大幅に防ぐことができます(ある形式のデータを別の形式のデータに比較的簡単に変換できるため)。また、データの受け渡しのセマンティクスはどこでも同じであるため、マルチプロセスまたはネットワーク化されたアプリケーションへの転送が容易になります。新しいデータを渡さずに、魔法のような隠れた状態の変化を想定することはできません。
データを渡す明確に定義されたインターフェース、そしてあなたは黄金です。そして、私はデータを意味します-あらゆる種類の魔法のことを行う方法を知っている「オブジェクト」ではありません。単純で純粋なデータ。
ちなみに、オブジェクトがプログラム内に場所を持たないということではありませんが、オブジェクトはデータに作用するものです。
また、データを処理するプログラムの部分を、実際にデータをシャトルする役割を担うプログラムの部分、およびデータをユーザーに表示する部分とは別にしておくようにしてください。私は知っています、それは全体が「あなたのビジネスロジックをあなたの永続性とUIレイヤーから分離しておく」ということです。
Use an Inversion of Control framework so that components don't have to know how to load their dependencies.
あなたが言っていることは実行できないか、実行できたとしても、実行するのはかなり難しく、利点はほとんどないと思います。
モジュール化は良い場合がありますが、制限があります。もちろん、一部の部分がAPIに依存するようにシステムを設計することはできますが、特定の実装には依存しません。それをお勧めしますが、「依存関係がまったくない」というのは幻想です。「コミュニケーション」はおそらく依存関係を生み出すでしょう。
ソフトウェアをモジュール化するのは良いことですが、行き過ぎです。
各システムに、その機能をRESTまたはWS-*インターフェースとして公開してもらいます。
しかし、もっと興味深い質問は、いつこれをしたいのかということです。選択したテクノロジーからできるだけ多くの生産性/パフォーマンスを引き出す必要があります。つまり、テクノロジー固有のソリューションを使用する必要があります。
これを行う唯一の方法は、ある形式の「ホワイトボード」システムであると思います。このシステムでは、コンポーネントが一般的にアクセス可能な領域に事実を書き留め、他のコンポーネントが事実を書き留めるのを観察します。このようなアーキテクチャは分散AIシステムで使用されていますが、実際の分散システムで使用されていることは聞いたことがありません。コンポーネントは明らかに、「ホワイトボード」メッセージの形式と、共有メモリなどの実際の実装に同意する必要があります。
100%モジュール化することは、努力する価値がないほど難しいでしょう。アプリケーションのクラスの場合、依存性注入と制御の反転を使用して、緩く結合できます。
より分散したシステムアプローチについて話している場合は、SOAPまたはREST(RESTは最も技術的に中立なものです)を使用して、各モジュールがコントラクトを提供できますが、その場合は、ある種の集中型メッセージングが必要になります。モジュールがどこにあるか、モジュールが呼び出されるようにそのコントラクトを認識し、成功/失敗を報告するためのある種の標準通信を実装するルーティングシステム。ただし、モジュールが通信するときに、モジュールがブラックホールに入り、二度と聞かれることはありません。 :)
一般化すればするほど、デバッグ、保守、理解が難しくなることを覚えておいてください。アプリケーションで何らかのパフォーマンスが必要な場合、これらのメソッドは実行できる最も遅い処理の一部になります。