第3章 ヘキサゴナルの「1枚絵」入門（城の中心を守る）🏰🛡️✨
![hex_ts_study_003[(./picture/hex_ts_study_003_dependency_rule_inward_only.png)
この章は「ヘキサゴナルって結局、何を守る絵なの？」を1枚の図でスッと理解する回だよ〜😊🌸 ここが腑に落ちると、後の Port / Adapter / テストがぜんぶラクになる✨
3-1. まずは結論：ヘキサゴナルの主役は「中心」🧠❤️
ヘキサゴナル（Ports & Adapters）は、ざっくり言うと
- 中心：アプリのルール（= ドメイン・ユースケース）🧠✨
- 外側：入出力（= 画面・HTTP・DB・外部API・ファイル…）🌐💾📄
を分けて、中心が外側に振り回されないようにする考え方だよ🛡️
Alistair Cockburn（提唱者）は「UIやDBがなくてもアプリが動いてテストできる形にする」と説明してるよ。つまり、中心は外側から独立していようね、ってこと😊🧪✨ (アリステア・コックバーン)
3-2. “1枚絵” の読み方（最短でわかる版）👀✨
まずはイメージ図（超ざっくり）👇
（外側の世界🌎）
UI/HTTP/CLI ──▶ [ Adapter 🧩 ] ──▶ ( Port 🔌 ) ──▶ 【中心🏰】
ルール🧠
DB/外部API ◀── [ Adapter 🧩 ] ◀── ( Port 🔌 ) ◀──
（外側の世界🌎）
✅ ここで覚えるポイントは3つだけ！
- 中心（🏰）がいちばん偉い：ルールを置く場所
- Port（🔌）は“約束（インターフェース）”：中心が「こう呼んでね」って決める
- Adapter（🧩）は“変換係”：外側の都合（HTTP/DB/SDK…）を中心の約束に合わせる
Cockburnも「外から来たイベントは Port に入り、Adapter が技術依存なものを変換して中心へ渡す。中心は入力装置の種類を知らない」と説明してるよ😊 (アリステア・コックバーン)
3-3. “六角形”は形じゃなくて「比喩」だよ🙆♀️✨
「え、六角形ってことは Port が6個必要なの？」って思いがちだけど…
- 6に意味はない
- 図として “いろんな方向にPortを生やせる” 余白が欲しかっただけ
って整理でOK😊 Wikipediaにも「6つの境界/Portがあるって意味じゃない。外部とのいろんなインターフェースを描く余白のため」って書かれてるよ✨ (ウィキペディア) Cockburn本人も同じ趣旨で「6が重要なんじゃなくて、描きやすいから」と言ってるよ〜🖊️ (アリステア・コックバーン)
3-4. “中心”って具体的に何が入るの？🏰🧠
中心はだいたいこの2階建て（イメージ）になることが多いよ😊
- Domain（ドメイン）：不変条件・状態・ルール（例：タイトル空はNG）🧷🚫
- UseCase（ユースケース）：手順・判断（例：追加→保存→返す）🧾✅
で、中心がやっちゃダメなのはこれ👇😱
- DBのテーブルやORMの型を知る
- HTTPのRequest/Responseを知る
- 外部SDKの例外や戻り値形式に依存する
これをやると「中心が外側に侵略される」＝城が燃える🔥🏰💥
3-5. 外側は何がいてもいい（UI/DB/外部API/テストも全部）🌐💾🧪✨
外側は “技術の世界” だから、何がいてもOK！
- Web（HTTP）🌐
- CLI（コマンド）⌨️
- DB（SQLite/Postgres…）💾
- ファイル（JSON）📄
- 外部API（決済/メール/地図…）📨🗺️
- 自動テスト（テストスクリプト）🧪
ポイントは「外側が増えても、中心が変わらない」こと💖 Cockburnも「同じ中心を、ユーザー/プログラム/自動テスト/バッチなどから等しく駆動できるようにする」と述べてるよ😊 (アリステア・コックバーン)
3-6. 依存の向き：この矢印が命🧭🔥
レイヤードでよくある依存はこう👇
- UI → Domain → DB
でもヘキサゴナルは、ここが変わる：
- UI → Domain ← DB
Martin Fowler の記事でも「依存が UI→domain→data から、UI→domain←data に変わる」と説明されてるよ✨ (martinfowler.com)
これが嬉しい理由😊💕
- DBを差し替えても中心は無傷（InMemory → File → SQL など）🔁
- UIを差し替えても中心は無傷（CLI → HTTP → GUI）🔁
- 中心の単体テストが超ラク（DBなしで爆速🧪⚡）
3-7. “城”たとえで超理解🏰🛡️🌸
- **城の本丸＝中心（ルール）**🏰
- **城門＝Port（約束）**🚪🔌
- **通訳・門番＝Adapter（変換係）**🧩
- **城下町＝外側（UI/DB/外部サービス）**🏘️
外側がどれだけ騒がしくても（新UI！DB移行！外部API変更！） 本丸の法律（ルール）が変わらなければ、国は安定するよね😊🛡️✨
3-8. 3分ミニ演習：あなたのアプリを“1枚絵”にしてみよ📝✨
いま作ったことある何か（ToDoでもブログでも）でOK！
Step 1️⃣：中心に書く（ルール）🧠
-
「これだけは守る」ルールを3つ書く
- 例：タイトル空NG／完了の二重適用NG／IDは必須…🧷
Step 2️⃣：外側に書く（入出力）🌐💾
- 画面、HTTP、DB、ファイル、外部API、など箇条書き
Step 3️⃣：境界に “Port” を書く🔌
-
「中心が欲しいもの」だけを約束にする
- 例：
TodoRepository（保存・取得だけ）みたいに最小で✂️
- 例：
Step 4️⃣：Adapter を置く🧩
- HTTP→入力変換、DB→保存変換、みたいに “通訳” を配置
これで、ヘキサゴナルの絵が完成🎉✨
3-9. AIに頼るなら：この章では「絵のチェック係」にするのが安全🤖✅
AIに丸投げすると崩れやすいのは「依存の向き」😵💫 だからこの章では、AIはレビュー係が超おすすめ💕
そのまま使える質問テンプレ👇
次の構成はヘキサゴナルの意図（中心の独立・依存逆転）を満たせていますか？
- 中心（domain/usecase）：
- ports（interfaces）：
- adapters（http/db/etc）：
チェック観点：
1) 中心がHTTP/DBの型を参照してない？
2) portsは中心側に定義されている？
3) adaptersが業務ルールを持って太ってない？
改善案も出して。
3-10. まとめ：この章で“頭に固定”したい1行🎁💖
「中心（ルール）を守るために、Portで約束して、Adapterで外側を変換する」 🏰🔌🧩✨
次の章からは、この1枚絵をベースに 「Portとは何か」「Adapterとは何か」をコードに落としていくよ〜😊💻✨