たとえば、ビルドプロセスまたはデプロイプロセスについて議論し、IDEから独立していることを確認する場合などです。これは「カップリング」ですか、それとも分離の分離と考えられているのですか、まったく異なるものですか？一般的な考え方は、プロセスまたはアーキテクチャに最小限の変数を導入することであり、障害が発生したときに障害の可能性のある点を特定するのが難しいことが大幅に軽減されます。それについての別の定義はありますか？"カップリング"はコードにのみ関連しているのでしょうか、あるいはソフトウェアコンポーネントとアーキテクチャにその用語を適用できますか？
全く異なるものです。
カップリングはコードです。
独立したツールは単なる独立したツールです。
マイクロソフトでは、独立したツールは悪い考えだと私に導きました。彼らは、1つのベンダーの統合されたツールスイートが良いことだと教えてくれます。
私は、カップリングがランタイムシステムの安定性やシステムの変更に関連するものであると考えています。
安定性を考慮すると、1つのコンポーネントの障害によって他のコンポーネントが故障した場合、カップリングが画像に入ります。例えば、2つのソフトウェアコンポーネントがTCP接続を介して直接通信している場合、一方のコンポーネントの障害は他方のコンポーネントがその作業を行うことができないことを意味します。システム全体がダウンしています。 2つのコンポーネントがメッセージキューを介して通信できるようにすることでデカップリングすると、各コンポーネントは、他のコンポーネントが存在しない場合でも独立して動作し続けることがあります（アプリケーションではこれが意味をなさないと仮定します）。
システムの変更を考慮すると、1つのモジュールでコードが変更された場合、多数の他のモジュールでコードを変更しなければならないということになります。
ビルド/デプロイメントツールで提供する例は、カップリングの形式ですが、ランタイムやコード結合などのアーキテクチャ上の問題を考慮した場合の心にはありません。