アーキテクチャ
フロントエンドは流行ではなく「ボトルネック移動」で変化している jQueryが解決した問題：ブラウザ差異 次のボトルネック：状態管理の崩壊 SPAが解決した問題：状態管理 SPAのボトルネック：初回表示 SSRが解決した問題：描画位置 SSRのボトルネック：不要…
SPAは「画面遷移をしないWeb」であり、だからマイクロフロントエンドと相性が良い MPAでフロントエンド分割が難しい本当の理由 SPAでは「1つのOSの上に複数アプリ」が動く マイクロフロントエンドの正体は「ルーティングの分散管理」 実際の実装は「アプリを…
レンダリング方式の選択は後から直せない設計項目 なぜ後から変更できないのか 具体例 実務で起きる典型的な失敗 ケース1：メディアサイトをSPAで構築 ケース2：管理画面をSSRで構築 リプレースになる技術的理由 ルーティング 認証 表面上の対策が効かない理…
SPAかSSRかの二択にしてはいけない なぜ単一方式では破綻するのか ハイブリッドレンダリングの基本設計 ルーティング分割 実装の考え方 認証との関係 データ取得戦略 実務でよくある失敗 すべてをSPAにする すべてをSSRにする 注意点 なぜこの設計が増えてい…
SPAは万能ではなく「用途が限定された最適解」 SPAが得意なこと 社内システムと相性が良い理由 公開サイトで起きる問題 初回表示の遅さ SEOとクローラ URLの意味が弱くなる 実務で起きる設計失敗 SSRとの違い 向き不向きの目安 注意点 まとめ SPAは万能では…
SDDで起きる最も危険な状態 ― 「仕様が読まれない」 アンチパターン1：仕様が設計ではなく説明書になる アンチパターン2：仕様が更新されない（凍結仕様） アンチパターン3：テストが仕様の代替になる アンチパターン4：仕様が巨大化する（過剰仕様） アンチ…
フロントエンド主導開発は可能。ただし条件を満たさないと破綻する フロントエンド主導開発とは何を指すのか 成立しないケース 成立する条件 1. クライアントの状態モデルが存在する** 2. API契約が先に定義される** 3. ビジネスルールの責務分離** SDDとの…
UI駆動型SDDは「最も分かりやすいが、最も壊れやすい仕様」になりやすい UI駆動型SDDとは何か なぜUIは仕様として扱いやすいのか UI駆動型SDDの最大の問題 ― 仕様の「因果」が逆転する 具体例：会員登録画面 UI駆動型SDDが壊れる技術的理由 UI駆動型SDDの典…
SDDでは仕様と設計は同じものではない 仕様とは何を指すのか 設計とは何を指すのか なぜこの分離が必要なのか 実際の開発で起きる変化 設計変更が安全になる理由 よくある失敗 ― 設計を仕様に入れてしまう 仕様の粒度はどこまで書くべきか 注意点 ― 仕様不足…
リポジトリパターンは「設計パターン」から始めると失敗します なぜ直接DBアクセスでは仕様を守れないのか ドメインモデルを通すと何が変わるか ではなぜRepositoryが必要になるのか Repositoryの本質は「コレクションのように扱うこと」 SDDとアプリケーシ…
AIは実装は得意、設計は苦手 典型例：レイヤードアーキテクチャの崩壊 AIは実装は得意、設計は苦手 AIに設計を任せると高確率で破綻します。 理由は単純で、AIはプログラムを書く能力と、システムを成立させる能力が別物だからです。AIは「どう書くか」には…
Javaが「中央集権」に見える理由 言語仕様と進化が中央で管理されている 標準ライブラリが強く、広い 実行環境（JVM）が強い支配力を持つ 実際に開発すると感じる「中央集権感」 ビルドと依存管理の作法が決まっている フレームワークが思想ごと提供される …
