私が導いた現時点での結論は、プレゼンター (Presenter) を軸に、ビュー (View)、ビューモデル (ViweModel)、おまけでモデル (Model) を用いるアーキテクチャーです。

一般的な概念としてはMVPに結構近い形です。

さて、このアーキテクチャーを用いる理由ですが、ゲームオブジェクト (GameObject) に付与したビヘイビアー (Behaviour) を疎結合とすることにあります。

特徴（メリット）は以下のようになります。

• 構造的役割と範囲が明確になる
• ビューモデル(VM)とモデル(M)部分を Unity IDE から分離できる
• DLLが分離できる
• テストがしやすい
• プレゼンター(P)を介したビューと(V)とビューモデル(VM)の双方向バインディングを実現できる
• デザイン側で生じた変更への対応労力が減少する

ただ、双方向バインディングを実現するためにはMVVMを実装可能にしなけらばならず、そのためには ReactiveProperty の実装が必要不可欠です。

そうすることによる課題（デメリット）は以下のようになります。

• 標準のUnityの作りがなんの参考にもならなくなる
• 開発難易度が上がる
• 問題が発生した場合の解決難易度が上がる
• 既存のシステムからの変更は新規開発と同じくらいの開発工数がかかる

ただし、こういったデメリットを考慮しても、得られるメリットのほうが断然大きいと思います。 （特に開発終盤、さらに開発完了後に受けられる恩恵が）

一度アーキテクチャー（フレームワーク）を経験したら、アーキテクチャーなしのUnityには戻れないと私自身は感じています。

これから本格的にUnity開発を行ってみたいという方は、是非とも自身のアーキテクチャーの構築に挑戦してみてはいかがでしょうか？