複雑な GUI を持つアプリケーションの設計について（Web アプリ編）を書いていたときに見ていた本は POSA 本だったのですが、以下のエントリでも同じようですね。

Flex2におけるアーキテクチャパターン @ 2007年08月 @ ratio - rational - irrational @ IDM

少なくともPACでいうAgentの開放/閉鎖は意識したほうがよさそうで、それだけでもイベントでワケワカになるのはかなり解消できます。

続報を強く期待します。Flex2 の固有事情とかもありそうです。

PAC で対処しやすい問題と対処しにくい問題があるから、その辺をどう考えるかですね。私はモデリングツールの開発経験が多いのですが、この種のアプリでは、構造ツリーとダイアグラムウィンドウという大きな枠組みがある場合が多いです。こういう大きな枠組みがあると、その単位で Agent を認識できるので、PAC の適用可能性が高く、スパゲティ対策に有効に働きます。

問題は、PAC が対応していない複雑性をどう制御するかでしょうか。たとえば、GUI アプリの状態やモードによって、中間レベル、下位レベルの Agent の枠を越えたアプリの制御を行わなくてはならなくなる場合があります。こういう場合、より上位の Agent に記述しますが、結局そのレベルの Agent の肥大化を招くことになります。これは、フォームやウィンドウのサブクラスを実装するタイプの開発スタイル（VB、Delphi 型）でよく遭遇します。

で、まだ整理されていないようですが、上記エントリに書かれているイベント翻訳（この言葉、知りませんでした。例外翻訳は聞いたことがありましたが。）や Command の適用などの話が出ていますから、その辺に対応策がありそうです。どういう解決策があるのか楽しみですね。

所詮さじ加減といわれるとそれまでですが・・・。(^^;