ストーリー
あなたのチームが半年間かけて開発してきたECサイトが、ようやくリリースされた。しかし、リリース直後から問題が噴出し始めた。
高
高橋アーキテクト
決済処理のバグを直したら、在庫管理がおかしくなった
高
高橋アーキテクト
新しい配送業者に対応したいのに、どこを変更すればいいのかわからない
高
高橋アーキテクト
テストを書きたいけど、データベースがないと何も動かない
困り果てたあなたに、高橋アーキテクトが声をかけた。
高
高橋アーキテクト
コードの品質は良いのに、全体の構造に問題があるんだ。“境界”がないから、変更の影響が至るところに広がってしまう。今月は、その”境界を守るアーキテクチャ”を学ぼう
アーキテクチャとは何か
ソフトウェアアーキテクチャとは、システムの基本構造とそれを構成する要素間の関係性のルールです。
┌──────────────────────────────────────────────┐
│ ソフトウェア │
│ │
│ コーディング: 個々のクラスや関数の書き方 │
│ 設計: モジュールやクラスの構成 │
│ アーキテクチャ: システム全体の構造と境界 │
│ │
│ 小 ←───── スコープ ─────→ 大 │
└──────────────────────────────────────────────┘アーキテクチャが解決する問題
| 問題 | アーキテクチャなし | アーキテクチャあり |
|---|---|---|
| 変更の影響範囲 | どこに波及するか不明 | 境界内に限定される |
| テスト | DB・外部APIが必須 | モック差し替えで独立テスト可能 |
| チーム分担 | 全員が全領域を触る | 境界ごとに担当を分けられる |
| 技術の入れ替え | 全体に影響 | アダプター層の差し替えで済む |
「動くコード」から「良い構造」へ
Month1-3で学んだSOLID原則やデザインパターンは、コードレベルの設計でした。アーキテクチャは、その一段上 — システム全体の設計です。
// これまで学んだこと（コードレベル）
class OrderService {
// 単一責任、依存性逆転、Strategyパターン...
}
// 今月学ぶこと（アーキテクチャレベル）
// OrderServiceはどの「層」に属する？
// データベースへのアクセスはどう分離する？
// 外部APIとの通信はどこに置く？
// 境界をどう定義する？高橋アーキテクトは言った。
「良いクラス設計は必要条件だが、十分条件ではない。100個の美しいクラスがあっても、それらの関係性が混沌としていたら、システムは破綻する。アーキテクチャとは、その関係性のルールを定めることだ」
Month 4 の全体像
| Step | テーマ | 時間 | 主なスキル |
|---|---|---|---|
| 1 | アーキテクチャ思考の目覚め | 2h | 関心の分離、依存性の方向 |
| 2 | ヘキサゴナルアーキテクチャ | 4h | Ports & Adapters |
| 3 | クリーンアーキテクチャ | 3h | 4層構造、DI、Use Case |
| 4 | ドメイン駆動設計（DDD） | 5h | Bounded Context、Aggregate |
| 5 | アーキテクチャの実践と評価 | 4h | フィットネス関数、トレードオフ |
| 6 | 最終試験 | 2h | 総合設計チャレンジ |
まとめ
| ポイント | 内容 |
|---|---|
| アーキテクチャ | システム全体の構造と境界のルール |
| 必要な理由 | 変更の影響範囲を限定し、テスト・分担・入れ替えを容易にする |
| 今月の目標 | 境界を守るアーキテクチャパターンを学び、実践する |
| メンター | 高橋アーキテクトが導く |
チェックリスト
- アーキテクチャの定義を理解した
- アーキテクチャが解決する4つの問題を把握した
- Month 4の全体像を確認した
次のステップへ
次は「レイヤードアーキテクチャの限界」を学びます。多くのプロジェクトで採用されている従来型のアーキテクチャが、なぜ限界を迎えるのかを理解しましょう。
推定読了時間: 15分