結合(Coupling)(リンク)とはプログラムモジュールが他のモジュールに依存する度合のことだ。疎結合は設計の優れた実装の典型的な目安で、疎結合な実装では高い可読性と保守性も備える。
Ian Robinson氏は新しいブログ記事(リンク)で、分散システムの設計手法（分散3層型、コマンド指向型、イベント指向型、救急サービス型が取り上げられている）が2種類の結合、つまり時間結合（temporal coupling）と挙動結合（behavioral coupling）に影響を与えることについて考察している。
氏は時間結合を次のように定義することから始める。:
メッセージの送信とメッセージハンドリングが連続しておこなわれる度合のことです。もしメッセージ送信において、受信側の可用状況に送信側が依存するのであれば時間的結合度が高いことになります。…（略）…。厳格に順番どおり処理がおこなわれていくプロセスや、処理結果が後の処理へ繰り越されるプロセスでは、リクエストに対する反応が返ってくるまで後続の処理が開始できませんが、これも同様に時間的に結合しているといえます。
挙動結合についてはこう定義している。:
複数のモジュールが振る舞いについての前提を共有する度合のことで、より詳しく言えば、分散相互作用において、どのような処理が実行されるか、その処理がどのように実行されるかという2つの責務に依存する度合のことです。極端に高い挙動結合を示すシステムでは、メッセージの送信側が何をするかを決定し、さらに受信側がそのリクエストをどのように処理するかを知っていることになります。…（略）…高い挙動結合のシステムでサービス利用者の要求変更に対応するためには、提供者を別におく必要になります。
従来の3層アーキテクチャが分散システムで用いられる時（分散3層システム）は一般的に同期型の相互作用を使って実装されるが（通信自体は非同期であったとしても）、時間結合も挙動結合も一般的に高くなりやすい。:
送信側が受信側に何をするか伝え、受信側はその指令通りに処理をおこないます。送信側と仲介機構は呼び出しスタックに空きができるまでブロックをおこうため、呼び出しチェインの処理が進むまでシステムリソースを事実上ロックしたり消費したりすることになります。このブロッキングのために上流のコンポーネントの自立性が損なわれますし、同時に下流のコンポーネントに要求される可用性への耐性度合いも高くなります。…（略）…これらの状況ではシステム全体の可用性は一番可用性の低い箇所に縛られてしまいますし、コンポーネントやサービスでエラーが起きる確率は同時確率になってしまいます。
コマンド指向型の設計を用いると一般的に時間結合度を低くすることができ、特に非同期相互作用をおこなうと効果がある。またオーケストレーション （ある処理を行うために必要なサービス間の複合的相互作用を管理する）エンジン実装でよく用いられる「再開可能（resumbale）」プログラミングも さらに結合度を低くする効果がある。:
（コマンド指向型設計では）送信側は基本的に何がなされるべきかを決定しますが、それがどう実行されるかは受信側に任されます。このような時、サービス利用者の要求の変化にできるだけ即してサービスを変更する（メッセー ジフォーマットや可能な動作を変更する）ために提供者を設置する方法もあります。
時間と振る舞いの両方の結合度が最も低くなるのはイベント指向型の設計においてだ。特に「再開可能」プログラミングモデルを伴っていると効果が大きい。:
受信側が何がなされるべきかを決定し、かつ受信したメッセージの内容に応じてどのように実行するかも決定します。ただエンドツーエンドのトランザクションや処理は実行パスを追うのが難しくなるかもしれません。コマンド指向型では「消火」処理をおこなうことを外に公開してビジネスプロセスの処理を引き受けますが、イベント指向型では「発火」の通知を受けて処理をおこないます。
最後に取り上げられている救急サービス型の設計はサービスを組み合わせて使うのが特徴で、任意の状態において、何が起こったかという情報を受け取り何をするかを決める。この設計の特徴は挙動結合がかなり低いことで、その実装を独立して変更することも可能にする。逆に処理が必要な時にそれをを受けてくれるサービスが利用できないといけないため、時間結合度は高くなる。多くのRESTfulシステムはこの設計に基づいてる。
時間結合度が一定のレベルになると、関係サービスの供給力に影響を与えます。多くのRESTfulシステムはこのタイプの設計を採用しています。URIテンプレートを使うシステムはハイパーメディアを使うシステム（クライアントが次に何ができるか、最適なリクエスト処理法は何かをサーバが管理する）より挙動結合の度合いが高くなりますが、クライアント側でポーリングとキャッシングがおこなうことで時間結合の問題をいくらか軽減することができます。
このブログ記事は分散システムの設計が、出来上がったシステムでの結合にどのように影響を与えるかについて興味深い分析をおこなっている。ただ残念なことに氏の見解がすべて正しいとはいえないようだ。
時間結合については、解決策はいたって単純だ。同期相互作用（通信ではない）は時間結合を強め、非同期相互作用は時間結合を低くする。氏のブログ記事ではいくつかの設計手法が取り上げられているが、それら全部で同期・非同期両方の相互作用を用いることができる。つまり出来上がるシステムの時間結合の度合を決めるのは設計手法ではなく、むしろ設計の中で用いられる相互作用によって決まるということだ。
挙動結合については、もう少し込み入った問題になる。そもそも挙動結合は微妙に異なるいくつもの定義がある。たとえばGrok Programmingにはこういう定義(リンク)がある。:
挙動結合は内容結合（content copuling）の一種ですが、別のモジュールによって作成されるデータに依存するのではなく、別のモジュールの実装（振る舞いなど）に縛られる形態のことです。
もしこの定義を採るなら、時間結合に対する最も一般的な解決策（common solution）(リンク)は、関係するモジュールの振る舞い作用から各モジュールを守る仲介機構になるだろう。この仲介機構もまた設計手法に関係なく導入が可能なものだ。