高凝集と疎結合、純粋なドメイン層。AIの力を最大限引き出す設計思想と、それを破らせない仕組み（10分バージョン）

by 株式会社カミナシ

Slide 1

Slide 1 text

⾼凝集と疎結合、純粋なドメイン層 AIの⼒を最⼤限引き出す設計思想とそれを破らせない仕組み (10分 ver) TSKaigi Mashup Kansai

Slide 2

Slide 2 text

⾃⼰紹介 ● 名前: Shimmy ● 所属: 株式会社カミナシ ○ ソフトウェアエンジニア ○ カミナシで新規プロダクトを開発中 ○ エンジニアは私1⼈、Claude Codeを活⽤している ● その他: ○ 最近は三国志のゲームに時間を取られています ○ AIのお陰で個⼈開発にまた⽕がついて、ゴリゴリコードを書いてます（AIが）

Slide 3

Slide 3 text

今⽇話すこと 1. AIの⼒を最⼤限引き出す設計 2. その設計をAIに破らせない仕組み

Slide 4

Slide 4 text

AIの⼒を最⼤限引き出す設計

Slide 5

Slide 5 text

条件1: 関⼼の分離関⼼事で分ける ● ある機能を修正したいとき、修正したい箇所がまとまっていると扱いやすい ● ファイルがすべて1ディレクトリの中にあるのでAIのコンテキストに載せやすい ● 並列にAI開発しても関⼼ごと別に分ければコンフリクトしにくい

Slide 6

Slide 6 text

条件2: テスト容易性 ● 純粋関数はテストしやすい ● 出⼒値ベーステスト: Inputを⼊れてOutputを検証する ● モック不要でAIに書かせやすい ● テスト実⾏が速い

Slide 7

Slide 7 text

条件3: 依存⽅向の決定層ごとに「何に依存してよいか」が決まっている

Slide 8

Slide 8 text

設計を守る3つのルール

Slide 9

Slide 9 text

ルール1: 純粋なドメイン層 domain/からinfrastructure/やserver/をimportしてはいけない ● domain層はどの層にも依存しない ● 純粋な関数と型だけの世界 ● drizzle-ormなどI/O系ライブラリのimportも禁⽌

Slide 10

Slide 10 text

ルール1: 純粋なドメイン層実際の構成

Slide 11

Slide 11 text

ルール2: Feature間の疎結合あるfeatureから別のfeatureを直接importしてはいけない ● 共有したいロジックはshared/に置く ● feature同⼠の連携が必要な場合は routes/層で組み⽴てる ● featureは互いの存在を知らない

Slide 12

Slide 12 text

ルール3: Public API境界 routes/からfeatures/を参照する際はindex.ts経由のみ ● domain/やserver/など内部ディレクトリを直接参照してはいけない ● index.tsで外部に公開したいものだけをexport

Slide 13

Slide 13 text

破られるルールから破れないガードレールに

Slide 14

Slide 14 text

なぜ「ルールを教える」だけでは⾜りないのか AIの出⼒速度に⼈間のレビューが追いつかない ● AIはすごい勢いでコードを書く ● レビュアーがボトルネックになる ● 何度も同じ指摘をしたくない

Slide 15

Slide 15 text

ガードレールとしての条件 ● 確定的であること ○ AGENT.mdは確率的 → 確定的なシステムが必要 ● 速くフィードバックできること（Shift Left） ○ AIの試⾏錯誤ループの中でフィードバックしたい

Slide 16

Slide 16 text

静的解析 dependency-cruiser

Slide 17

Slide 17 text

dependency-cruiserで設計を強制する import⽂を静的解析して依存関係のルール違反を検出するツール ● 設計思想をdependency-cruiserのルールとする ● 新規プロダクトでは12個のルールを定義

Slide 18

Slide 18 text

ルール定義①: 純粋なドメイン層 domain/からinfrastructure/やserver/をimportするとエラー

Slide 19

Slide 19 text

ルール定義②: Feature間の疎結合同⼀feature内はOK。別featureを直接importするとエラー

Slide 20

Slide 20 text

ルール定義③: Public API境界 index.tsを通さずにfeature内部を参照するとエラー

Slide 21

Slide 21 text

その他の静的解析ツール ● knip: 未使⽤コードを検出 ○ AI実装で⽣まれる未使⽤exportやファイルを⾃動検出 ● Biome: コード品質を統⼀ ○ any型禁⽌、⾮nullアサーション禁⽌、awaitされていないPromise検出

Slide 22

Slide 22 text

Git hooksで統合する

Slide 23

Slide 23 text

lefthook: コミット前に⾃動で弾く ● pre-commit: Biomeのチェック + dependency-cruiser ● pre-push: 型チェック + knip + テスト

Slide 24

Slide 24 text

開発フローアウトプットではなく、プロセスを信頼できるものにする 1. AIにコードを書かせる 2. git commit  a. Biome + dependency-cruiser が⾛る b. 設計違反があればエラー c. → AIが⾃動修正 3. git push  a. → 型チェック + knip + テストが⾛る

Slide 25

Slide 25 text

まとめ

Slide 26

Slide 26 text

3つ設計思想を振り返る ● 関⼼の分離 ○ Feature内は⾼凝集、Feature間は疎結合 ● 依存⽅向の決定 ○ domain層は純粋に。repository, serverから利⽤ ● テスト容易性 ○ テストしやすい関数に。

Slide 27

Slide 27 text

設計思想をコードで強制する dependency-cruiserで設計思想をガードレールに ● domain層から他の層をimportしたらエラー ● 別featureを直接importしたらエラー ● index.tsを通さずfeature内部を参照したらエラー knip + Biome も活⽤し、lefthooksで確定的に実⾏