一連の書き込み見ました。GraphQLとCQRSに対する温度感等理解できました。そう、Laravelの影響受けすぎてるのと僕が実務でRestfulAPIしかやったことないので、あの記事の中でも暗黙の前提になっているんですよね。全く異論無し。ただ現状のシェアみてもFWとしてどうすべきかは微妙かなと。ChatGPTとの壁打ちでもGraphQL対応するとFWの内部設計まで影響が避けられなさそうな印象を受けたので
CQRSについてはガチの実装や制限はともかく、中～高レベル帯で本格導入前の触りだけ入れるぐらいはしてもいいのかなという気がしました。知見ありがとうございます。

すいません！CQRS/GraphQLについて書かれてた書き込みがあったと思うんですが見当たらないのでここから質問させてください。
実装経験もないのであれなんですが負荷のかかる場所にピンポイントで導入するイメージがあります。うちにも試しにDynamoDB絡めて実装した人がいて、退職してブラックボックス化してる箇所あるんですけどw
ただその認識が誤っていて、Webアプリ全体に適用するのが普通（ないしmpywさんの肌感として普遍性があるのである程度の規模感では適用した方がよい）と考えているということでしょうか。

まさしくLaravelにおいて「なんちゃってクリーンアーキテクチャ」の反響が大きかった理由だと思っています。多分あの記事だったら当然みたいな扱いになってたServiceクラス切るのすら正直暗黙知状態でネットにも記事がなく、共有具合が若干怪しいんですよね。実質2段階スケールさせて、ある程度の業務用アプリなら安定して捌ける方法論を提示したのは大きいと思います。

個人の感覚としては現状で十分シェア取れると思っています。強いて言うならスケーリングいらなくていきなり大規模アプリ作る際の選定でNest.jsとの差別化が問題になりそうですが、関数型ベースですって売り込みしたらフロントからの転向組も多いTSならまぁイチコロよw（雑）
あとmpywさんほど設計力高ければ最大の問題がドメインモデリングや分割になるのも分かるんですけど、世には自分含め、スケーリングのやり方が分からないで不安、定番のやり方があるなら乗っかりたいって層の方がずっと多いので……（FatController,FatModel,Service乱立のコードを見ながら）

ごめんなさい、結論だけ読んだらどこがmpywさんやふわせぐさんの影響受けてるんや、MVC完全になくなってるしUseCase/Action出てきてなくね、ってなると思います。
ただこれもChatGPTと散々話してて、（将来のROPへの接続を視野に）処理のパイプラインとして構造を表に出してMVCという今となっては形骸化した抽象化は捨てて、一旦実務よりの抽象化した方がいいんじゃないかという結論に達しました。その中でもUseCase/Actionの概念は中規模以上だと有用だし残るだろうと。換骨奪胎しすぎて原型留めてないんで分かりにくいですが、自分の中ではめっちゃ影響受けてます。

順番前後しますが、FB感謝です。そうアプリのアプリスケーリングについては、完全解決していません。別リプでも回答しますがドメイン分割についてはFW（ないしプログラム）では限界があるので……。まぁでもシステマチックにできる部分については相当改善するし、FWの強みとしての価値は十二分あるという認識です。あ、あとお礼については禅からご確認ください。

付録のChatGPTログでもそこらへんの対話してて（長すぎるので読まなくてOK）、プログラムによる決定論的なドメイン解析は難しい（そもそもルール化できてない、精度的に）、AIにコード丸々投げて解析させるにしてもinputされてない情報は考慮に限界があるので精度にも限界があるだろうという見解でした。
それでAIにドメイン分割のアドバイスコマンド（とFB解析してのマイグレーションプラン作成コマンド）とか作るべきかとも思いましたが、それってIDEのチャット欄やAIのCLIツールの指示入力欄でええやんとw FWとしてはドメイン分割としてはマイグレーション補助が限界という結論に達しました

ほんのラーメン代程度ですがお礼もさせていただきます！