アプリケーションアーキテクチャ概要 ― 内側の約束事 ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「アプリケーションアーキテクチャ」カテゴリの入口として、この領域全体を俯瞰する記事です。

モノリスかマイクロサービスかを論じる前に、アプリ内部のコードが統一された書き方になっていないと、どんな全体構造も絵に描いた餅になります。本記事ではソフトウェアアーキテクチャとの違いと、クラス設計・命名・ドメインロジック・エラーハンドリングなど内部構造の決めごとの全体像を示します。

このカテゴリの全記事一覧・各記事で学べるポイントは以下のページにまとめています。

アプリケーションアーキテクチャ 記事一覧 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-index-app/

本記事のテーマについてさらに詳しく知りたい方は『アプリケーションアーキテクチャ設計パターン』・『アーキテクトの教科書』も参考にしてみてください。

そもそもアプリケーションアーキテクチャとは何か

チーム料理を想像してください。5人のシェフが同じ厨房で働くとき、「包丁はここに置く」「塩加減はこの基準」「盛り付けはこの順番」というルールがないと、料理のたびに味も仕上がりもバラバラになります。

アプリケーションアーキテクチャはチーム全員が同じコードの書き方で開発できるようにする内部の約束事です。クラス設計・命名規則・ドメインロジックの置き場所・エラーハンドリングの方針など、コードの「品質基準」を揃えます。これが手薄なプロジェクトは、レビューのたびに「この書き方でいいの？」の議論が再燃して生産性が落ち続けます。地味な規約の徹底が、日々の生産性と長期の保守性を静かに支えています。

ソフトウェアアーキテクチャとの違い

言葉が似ているため混同されがちですが、両者は対象の粒度が根本的に異なる設計です。

家で例えるなら、ソフトウェアアーキテクチャは間取り図、アプリケーションアーキテクチャは「各部屋の家具配置・コンセントの位置・壁紙の柄」です。間取りを変えるには壁を壊す大工事が必要ですが、家具は比較的動かしやすい。そのぶん日々の暮らしやすさは家具配置で決まる、という関係です。

両者を分けて考える理由は、混ぜると議論の抽象度がバラついて会議が噛み合わなくなるからです。「マイクロサービスにすべきか」という大枠の話に「その中のクラスはどう分けるのか」が割り込む状態では、設計議論が前に進みません。「アーキテクト」と「テックリード」で責任を分担し、それぞれが違うレイヤーの決定を担うのが健全です。キャリア初期のエンジニアは「クラス設計を頑張ればアーキテクチャが良くなる」と思い込みがちですが、外側の判断を間違えているとどれだけクラスを綺麗に書いても挽回できません。

ドメインロジックの2大方針

内部設計の最初の分岐は、ビジネスロジックをどう表現するかです。処理の流れをそのまま関数化する手続き型（Transaction Script）は、小規模・CRUD中心・短期プロジェクトに向きます。ビジネスロジックをドメインオブジェクト内に凝集させるリッチドメイン（DDD）は、大規模・複雑な業務ロジック・長期運用で効きます。

「小さく始めて、複雑化したらリッチドメインに移行」という段階的な設計変更が一般的で、最初からDDDありきで始めないのが健全です。またどちらの方針でも、「依存の方向を内側に向ける」（DB・UI・FWの変更がビジネスロジックに波及しない）というクリーンアーキテクチャの原則は共通の土台になります。

どう選べばいいのか ― 規模×業務複雑度

投資配分はプロジェクトの性質で変わります。新規CRUD中心アプリなら命名規則とLinter/Formatterの徹底に注力し、ドメインロジックは手続き型で十分です。複雑な業務ロジック（保険・金融・会計）ならドメインモデルを厚く設計し、業務用語との一致（ユビキタス言語）を優先します。複数チームのマイクロサービスならディレクトリ構成・API契約・エラー規約のチーム横断統一が本丸です。レガシー改修は既存流儀への敬意が最優先で、新規追加部分だけ段階的に規約を適用します。新しい規約の一気の全面適用は失敗パターンです。

「1ファイル300行・1メソッド50行・循環的複雑度10」が定量ガードレールの定番です。これを超えたら分割の合図で、ESLint・SonarQubeで自動検出するのが現代流です。「新規CRUD画面にクリーン4層を適用」は典型的な過剰設計で、MVPにDDDは過剰、巨大プロジェクトで手続き型は破綻します。

このカテゴリの知識構造

このカテゴリは全5記事で構成され、設計原則から具体的なルールへと段階的に降りていく構造です。設計の骨格であるクラス設計とドメインロジックの方針を先に決めると、命名やエラー処理のルールが自然に導かれます。DDDを採用するならユビキタス言語が前提になり、手続き型ならシンプルなエラーコード返却で十分かもしれません。

このカテゴリは他カテゴリと比べて変更コストが低い（Two-way Door）ですが、チーム全員が毎日触れる領域なので、放置すると生産性への影響が最も大きくなります。

AI判断軸 ― 規約はAIへの制約になる

型と規約の明示がAIの生成品質を決める

型（TypeScript・Zod・Protocol Buffers）と規約（ディレクトリ構造・命名ルール・エラーハンドリング方針）がコードで明示されていれば、AIはそれに従った一貫性のあるコードを生成します。逆に規約が口頭合意やConfluenceにしかない場合、AIは毎回異なるスタイルのコードを出し、レビューコストが増大します。

小さなモジュールはAIのコンテキストに収まる

「1ファイル1責務・300行以内」のモジュール粒度で設計しておくと、AIに修正を依頼する際にモジュール単位でコンテキストを渡せます。巨大なクラスや複数責務を持つファイルではAIが全体像を把握できず、意図しない副作用のあるコードを生成しがちです。人間のレビューにも効くので、この方向は二重に得です。

やってはいけないこと

各論記事で詳しく触れる禁じ手のうち、内部構造レベルで押さえるべき核心を6つに絞ります。

アプリケーションアーキテクチャは規約の徹底で決まります。ツールで機械的に強制するのが唯一の解です。

決めるべきこと — 自分のプロジェクトでの答えは？

以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。それぞれの詳細は配下の各論記事で扱います。

• クラス構成（単一責任・継承・委譲）
• ドメインロジック（手続き型 / リッチドメイン）
• エラーハンドリングポリシー（例外 / Result型）
• 命名規則と概念モデル（ユビキタス言語・用語集）
• コード規約（フォーマッタ・リンター・レビュー方針）
• ディレクトリ構成と依存方向のルール
• テスト戦略（ユニット / 統合 / E2Eのバランス）

まとめ

本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「アプリケーションアーキテクチャ」カテゴリの入口として、内部構造の規約をどう決めるかの全体像を解説しました。如何だったでしょうか。

思想の選択より規約の徹底、過剰設計より段階的成長、人間のためだけでなくAIへの制約として設計する。これがアプリケーションアーキテクチャの3つの核です。

次回からはこの領域の各論に入り、まずクラス設計（SOLID原則・継承vs委譲）から解説していきます。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

本記事で扱った内容の詳細は AWS アーキテクチャセンター も合わせて参考にしてください。

それでは次の記事も閲覧いただけると幸いです。