たとえば、ビルドまたはデプロイ プロセスについて議論し、それが IDE から独立していることを確認する場合などです。これは「カップリング」ですか、それとも懸念の分離と見なされますか、それともまったく異なるものですか? 一般的な概念は、プロセスまたはアーキテクチャに導入する変数の数を最小限に抑えることです。これにより、障害が発生した場合に、障害の可能性のあるポイントを特定する難しさが大幅に軽減されます。そのための別の定義はありますか?
2 に答える
結合は、実行時のシステムの安定性またはシステムの変更に関連するものとして特徴付けられます。
安定性を考慮すると、1 つのコンポーネントの障害が他のコンポーネントの障害を引き起こす場合、カップリングが問題になります。たとえば、2 つのソフトウェア コンポーネントが TCP 接続を介して直接通信している場合、1 つのコンポーネントに障害が発生すると、もう 1 つのコンポーネントが機能しなくなります。システム全体がダウンしています。2 つのコンポーネントが (たとえば) メッセージ キューを介して通信できるようにすることで分離すると、各コンポーネントは、他のコンポーネントがなくても独立して動作し続ける可能性があります (これがアプリケーションで理にかなっている場合)。
システムの変更を検討する場合、1 つのモジュールのコードを変更すると、他の多数のモジュールのコードを変更しなければならない場合に、結合が問題になります。
ビルド/デプロイ ツールで示した例は結合の一形態ですが、ランタイムやコードの結合などのアーキテクチャの問題を検討するときに人々が実際に考えていることではありません。
まったく違うもの。
カップリングはコードです。
独立したツールは、独立したツールです。
Microsoft は、独立したツールは良くない考えだと私に信じ込ませました。彼らは、1 つのベンダーの統合ツール スイートは良いことだと言っています。