アーキテクチャの議論を実装なしで語るのは、非職人のダメなところ。

さいしょに、机上の空論を防ぐために
科学では実験。
ソフトウェア工学では実装。

この手のアーキテクチャ議論の　ネックになる　もしくは、語られない部分は

１．人員
２．実質的なコストパフォーマンス
３．つきあい

の3点。

一番大きいのが１の人員。
たとえば、Ｆ１ってすごいよね。というアーキテクチャーにしても、それを作れる・使いこなせる
Ｆ１ドライバーがいないなら、アーキテクチャーはカローラなどの大衆車にせざるを得ない。

現実問題として、現在の人員で、もしくは、追加予定の人員で、開発可能かどうか？
という議論なしに、アーキテクチャーを議論してもしょうがない。

また、どうように、学習コストや潜在バグの可能性の話もある。

どんなに、すぐれたアーキテクチャーであろうとも、
学習コストが高すぎで誰も使えないとか、

学習コストまでふまえると、既存のアーキテクチャーの方がよいとか。
いうのはよくある。

また、潜在バグの可能性もあり、新しいアーキテクチャーなどは、
論理的には優れているけど、実装はショボかったりする。

こういうことをいうと、学習コストは1度払えばいいのだから、10年間では得をするとかそういう話もあるが
10年後には別なアーキテクチャーができているという議論もあるので。

あくまで対象とすべきは、今実装する物と近々に実装する物である。
とすると、いま抱えている人員にとって、どんなアーキテクチャーがベストか？という話になる。

２．コスト。
人員の話や、学習コストの話、さらには、ハードウェアの物理限界の話。サーバークライアント連携の物理限界の話もある。

クライアント単体でみると、優れたアーキテクチャーでも、サーバーとクライアント逢わせると、優れていない（サーバが輻輳する）ようなアーキテクチャもある。

ようするに。

人員のコスト・学習コスト・ハード・ソフト・期間・サーバー・クライアントなどなど要素数が多いにもかかわらず

アーキテクチャの議論でされるのは、その中のわずか、数ファクタで、話をする人が得意なところだけ。

よって、

結局的には、実装された物からくる経験は、実地というリアルによりすべての要素が検討された後なので、
聞く価値があるが、実装されてない物は、未検討の要素が多すぎて、コストパフォーマンスの要素がトータルで信用できない。

実装してから言ってくれ。

３．つきあい。

どんなに優れたアーキテクチャーでも、資本関係とか、お客様のつきあいとかで使えないこともある。
アーキテクチャーは政治です。

優劣以外にもファクターはいっぱいあるんです。