golangにおける APIアーキテクチャ設計 2018/5/28 @ gopher dojo LT 　 Hisayuki Matsuki

自己紹介 松木 久幸 https://github.com/matsu0228 2 Server Side Engineer Python/Django Ruby on Rails

What’s this? ● Agenda 1. アーキテクチャ設計 2. golangで書いてみた 3. 課題点/疑問点 ● 話すこと ○ 概念的な話 ○ packageの分け方 / interface ○ サンプルコード（https://github.com/matsu0228/go_sandbox/tree/master/cleanArch） ● 話さないこと ○ どのようなFramework/Libraryを使うか ○ 例：database接続には○○を使う 3

1-1.APIアーキテクチャ設計 ● ある程度の規模のAPIサーバーをgolangで構築する ○ GET /product/1795, POST /product/new ○ GET /campaign/5235 ○ … ● 要件 ○ 修正時の影響範囲が限定的 　かつ ○ テストしやすい（databaseまわりなど） 4

1-2.Clean Architecture ● 依存関係は一方方向（外から内側） ● 上記に矛盾が発生しないよう、DIP(依存関係逆転の原則) ○ Go: IFを活用 原文: https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html 5

2-1. レイヤー ● Entity ○ structを定義 ● Usecase ○ ビジネスロジックを定義 ○ <= IF:product.repository ● Repository ○ database操作を定義 ○ <= database/sql (ref: sqlx) ● HttpDeliver ○ webサーバーを定義 ○ <= IF:product.usecase 6

2-2. レイヤー：Entity ● Entity ○ structを定義 7

2-3. レイヤー：Repository ● Repository ○ database操作を定義 ○ <= database/sql (ref: sqlx) 8

2-4. レイヤー：Usecase ● Usecase ○ ビジネスロジックを定義 ○ <= IF:product.repository 9

2-5. レイヤー：Usecase ● 矛盾が発生しないよう、DIP(依存関係逆転の原則) 10

2-6. ディレクトリ構成 ● 1st dir: エンドポイント種別 ○ campaign, product, ... ,common ● 2nd dir: layer ○ -> 影響を限定的に 11

2-7. Usecaseのテスト ● DatabaseをMockで差し替えて、ビジネスロジックのテストがし やすい ○ <= IF:product.repository 12

3.課題点/疑問点 ● そもそも１プロセスで、複数APIエンドポイント提供する？ ● 小規模なAPIでは、複雑なコードになりデメリットも大きそう（慣 れの問題？） ○ 修正ごとに、IFを調整したり ○ 配置場所が悪いと拡張性が悪くなりそうだったり 13

まとめ ● ある程度の規模のAPIサーバーを、golangで構築する際の設計 について検討 ○ 具体的なサンプルコードを基に、概要を説明 ○ サンプルコード（https://github.com/matsu0228/go_sandbox/tree/master/cleanArch） ● golangにおけるinterfaceの利用例を提示 ● このLTをきっかけに、アーキテクチャ設計について知見を深め られればと 14