「広い」メッセージングって何だろう

Webで「Smalltalk, Smalltalk, Smalltalk」と三度唱えると、sumimさんを召還することができます。実際には一度でも大丈夫です。（sumimさん、ごめんなさい）。
で。
大事なのは、オブジェクト…じゃなくて、メッセージングというエントリを読みながらふと思いついたことを書きます。まとまっていないのはご容赦。
要するに「クラスよりも広い概念としてパッケージがあるとしたら、メッセージングよりも広い概念は何だろう」という疑問です。

そんなメッセージング大好き！な私でも、SELF みたいに代入にいたるまで、ほんとにすべてをメッセージにしてしまうのは、さすがにちょっと（いや、かなり…）使いにくさを感じます。

http://d.hatena.ne.jp/sumim/20070310/p1

↑ということは、メッセージという疎結合なつながり方と、もっと密結合なつながり方があるということですよね。ということは逆方向にextrapolateして、メッセージよりも疎結合なつながり方はあるのかな、と思ったのです。
さらにいうなら、名前空間を考えたときにローカルなブロック内、メソッド内、クラス内、パッケージ内、プログラム内…というような入れ子構造があるように、メッセージングという世界でも入れ子構造のようなものはあるのかな、と思ったのです。
世の中を見渡してみると、プログラムの中のメソッド呼び出しと、WebサービスのAPI呼び出しというのはそれに近いイメージなのかもしれませんけれど。
以上、何だか曖昧な話ですみませんが、思いついたので書きました。思いついたときには面白いと思ったのですが、書いているうちにそれほどでもなくなってしまいました（←おい）。
追記：
sumimさんから：

代入（バインド）が密側のものとするならば、メンバ関数（メソッド）の動的コールは中庸、非同期の処理間の連携はさらに疎側にあるもの…と考えるというのではいかがでしょうか

コメント感謝。なるほど。確かにそれはありますね。わたしもちょうど、synchronousな呼び出しよりも、asynchronousな呼び出しのほうが「疎」っぽいなあと思っていたところでした。なぜかというと、asynchronousなほうが、callerとcallee双方の自由度が高いからですね。電話で相手に呼びかけるのとメールで呼びかけるのとの違いかもしれません。（…それってWebの「召喚」の話題に近いな…）
同期／非同期のほかにも、共有の度合いの次元もありますね。プロセス（疎）とスレッド（密）のように。…あ、世界のどこかでは誰かがきちんと整理していそうな話題…。