1. はじめに：なぜ「整理整頓」が設計に必要なのか？
こんにちは。これから皆さんと一緒に、長く愛されるプログラムを作るための「整理整頓の極意」を学んでいきましょう。
ソフトウェアの開発を料理に例えてみてください。プログラムの設計（アーキテクチャ）とは、いわば「台所のレイアウト」です。もし、台所が道具や材料で散らかっていたらどうなるでしょうか？必要な道具が見つからず、賞味期限切れの材料を見落とし、料理を作るたびにストレスが溜まってしまいます。
「良いアーキテクチャ」と「悪いアーキテクチャ」では、開発の体験がこれほどまでに変わります。
| 項目 | 良いアーキテクチャ（整理された台所） | 悪いアーキテクチャ（散らかった台所） |
| 作業効率 | 道具の定位置が決まっており、迷わず調理（実装）に集中できる。 | どこに何があるか分からず、作業が停滞する。 |
| 修正の容易さ | 特定の引き出しだけを整理するように、安全にコードを変更できる。 | どこかを変えると、山積みのゴミが崩れるように無関係な場所まで壊れる。 |
| バグの発見 | 構造が明快なので、不具合の原因をすぐに見つけ出せる。 | ゴミの山の中から失くしたスプーンを探すような絶望感がある。 |
| チーム開発 | 境界線が明確で、複数人で作業してもお互いの邪魔にならない。 | 役割が曖昧で、誰かが鍋を洗うと誰かの包丁がなくなるような混乱が起きる。 |
整理整頓のメリットを理解したところで、次は「何をどこに置くべきか」という具体的な仕分けの基準を見ていきましょう。
--------------------------------------------------------------------------------
2. 「ビジネスルール」と「技術的な詳細」の境界線
クリーンアーキテクチャの根幹には、ソフトウェアの要素を「ビジネスルール（核となる仕組み）」と「技術的な詳細（実現するための手段）」の2つに厳格に分けるという考え方があります。
例えば、スーパーマーケットの「100円で1ポイント付与」というルールや、銀行の「利息計算」、ホテルの「3日前までのキャンセルは無料」といったポリシーを想像してください。これらは、たとえ最新のクラウドを使わず「手書きの台帳」で管理したとしても、ルールそのものは変わりません。これがビジネスルールです。
一方で、データをMySQLに保存するかPostgreSQLにするか、画面をWebで出すかスマホアプリにするかといった事柄は、単なる技術的な詳細に過ぎません。
| 項目 | ビジネスルール（何をするか） | 技術的な詳細（どうやって実現するか） |
| 意味 | サービスの根幹。技術がなくても成立する「核」。 | ルールを動かすための具体的な「道具」。 |
| 具体例 | 宿泊3日前までのキャンセルは無料、ポイント計算。 | MySQL、AWS、JSON形式、Echo（Webフレームワーク）。 |
| 変更の頻度 | めったに変更されない（ビジネスの根幹）。 | 比較的よく変更・交換される（技術の進化や都合）。 |
守るべき「核」が明確になったら、次はそれらを包み込む「お菓子の箱」のような階層構造について学びます。
--------------------------------------------------------------------------------
3. クリーンアーキテクチャの4つの層：チョコレートの箱の構造
クリーンアーキテクチャは、大切な中身を外側から順に包み込む「チョコレートの箱」のような層構造をしています。
- エンティティ（Entities）：チョコレート本体 最も内側に位置する、ビジネスの基本的なルールとデータ構造です。「ユーザー名は3文字以上」といった不変のバリデーションが含まれます。
- ユースケース（Use Cases）：個包装 「ユーザーを登録する」といった、具体的な業務の手順（フロー）を定義します。チョコレートを「誰に、いつ届けるか」という指示書のようなものです。
- インターフェースアダプター（Interface Adapters）：仕切り 内側の層と外側の技術を隔てる「仕切り（しきり）」の役割です。この仕切りがあるおかげで、ユースケースという繊細な中身が、外箱（WebやDB）に直接触れて汚染されるのを防ぎます。
- フレームワーク＆ドライバー（Frameworks & Drivers）：外箱 最も外側にある、具体的な技術の詳細です。データベース（MySQL等）やWebフレームワーク（Echo等）がここに該当します。箱のデザインを変えても中身の味に影響しないように、最も交換しやすい部分です。
この層構造を維持するために、最も守らなければならない「絶対的なルール」が1つだけあります。
--------------------------------------------------------------------------------
4. 黄金のルール：依存関係は常に「内側」へ
クリーンアーキテクチャにおける最も重要な掟、それは「依存関係の方向」です。
黄金のルール： ソースコードの依存性は、常に「内側（ビジネスルール）」に向かっていなければならない。
これをレストランのキッチンに例えてみましょう。
- 内側（料理人とレシピ）： ハンバーグの作り方やレシピ。これが「核」です。
- 外側（注文システム）： タブレット、スマホ、あるいは店員のメモ。これらは「詳細」です。
料理のレシピ（内側）は、注文がタブレットで来ようが手書きで来ようが、作り方を変える必要はありません。「内側は外側を気にしない」のです。逆に、注文システム（外側）は、どんな料理が作れるのか（レシピ）を知っていなければ機能しません。
このルールのメリット
- 外側の変更に強い: Go 1.22で標準ライブラリのルーティングが強化された際、Webフレームワーク（Echo等）から標準の
net/httpへ乗り換えることも、外側だけの変更で完結します。 - テストが容易: データベースやネットワークがなくても、内側のレシピ（ビジネスルール）だけでテストが可能です。
- 独立性の確保: データベースをMySQLから別のものへ差し替えても、核となるロジックは1行も書き換える必要がありません。
設計の理論がわかったら、次はこれを実際のGoプロジェクトでどのように配置するのか、棚割りの設計図を見てみましょう。
--------------------------------------------------------------------------------
5. 実践：Goプロジェクトの「棚割り」構成
Go言語でこの構造を実装する際の、標準的なディレクトリ構造です。
myapp/
├── cmd/ # エンジンを始動させる「イグニッションキー」
│ └── main.go # 依存関係を注入（DI）し、アプリを起動する場所
├── domain/ # 【エンティティ層】ビジネスロジックの核
│ ├── entity/ # データ構造と基本バリデーション
│ └── repository/ # 抽象的なデータ操作（インターフェース）
├── usecase/ # 【ユースケース層】具体的な業務の流れ
├── interface/ # 【インターフェースアダプター層】
│ ├── handler/ # Webリクエストの受け口
│ └── repository/ # データベース操作の具体名（SQL等）
└── infrastructure/ # 【フレームワーク＆ドライバー層】外部接続
├── database.go # DB接続の管理
└── server.go # Echoや標準httpなどのサーバー設定
cmd/ は車の「キー」のようなものです。ここで全てのパーツを組み立て、インターフェースに対して「本物のデータベース」をプラグイン（注入）します。これにより、各層が独立した状態を保てるのです。
--------------------------------------------------------------------------------
6. 実装のエッセンス：コードで見る各層の役割
優れた実装が満たすべき条件をチェックリストで確認しましょう。
エンティティ層：ビジネスルールの守護者
- [ ]
len(name) < 3のような、ドメイン固有のバリデーションがメソッドとして実装されているか。 - [ ] 外部のライブラリやDBに依存していない「純粋なGoコード」か。
- [ ] **Goの「ゼロ値」**を活かし、定義した瞬間から安全に使えるようになっているか。
リポジトリインターフェース：データの抽象化
- [ ] メソッド名に「MySQL」や「JSON」といった具体的な技術名が含まれていないか。
- [ ]
SaveUserやFindByIDのように、ビジネス上の意図が伝わる名前になっているか。 - [ ]
ErrUserNotFoundなどの、ドメイン特有のエラーが定義されているか。
ユースケース層：業務の指揮者
- [ ] 「まず重複をチェックし、次に保存する」といった手順（フロー）を制御しているか。
- [ ] 具体的なDB操作は知らず、インターフェース（抽象）を通じて操作しているか。
- [ ] 1つのメソッドが1つの業務目標（例：ユーザー登録）に集中しているか。
--------------------------------------------------------------------------------
7. まとめ：整理された設計がもたらす最高の開発体験
クリーンアーキテクチャを導入することは、単なるルールの遵守ではなく、長期的にチーム全員が笑顔で開発を続けるための投資です。
3つの重要ポイント
- 修正の恐怖からの解放: 影響範囲が特定の層に閉じ込められるため、どこを変えたらどこが壊れるかわからない不安が消えます。
- 検証の高速化: データベースを立ち上げなくてもビジネスの核心をテストでき、自信を持ってリリースできます。
- チームの調和: 境界線がはっきりすることで、役割分担がスムーズになり、お互いのコードを尊重できる環境が整います。
設計とは、複雑にすることではなく、シンプルに保つための努力です。「データベースが変更されたくらいで、シェフ（開発者）を泣かせてはいけない」——この言葉を胸に、明日からあなたのコードを少しずつ整理整頓してみてください。
