アプリケーションアーキテクチャ設計に関する覚書（Go）

1. 前提条件

2. 基本的な考え方

3. プロジェクト構造

4. src以下の構造

ディレクトリ構造

src/
├─ config/
├─ handler/
├─ lib/
├─ mock/
├─ model/
├─ repository/
├─ usecase/
├─ validator/
└─ main.go

config

• アプリケーションの設定を管理
• 典型的にはconfig/config.goだけが配置される

package config

type Config struct {
    ...
}

handler

• MVCにおけるコントローラ
• HTTPリクエストの受信とレスポンスの返却を担当する
• HTTPリクエストに関する処理はこのレイヤーで完結させ、これ以降のレイヤーに影響させてはいけない

lib

• フレームワークのミドルウェアやラッパーなど

mock

• ユニットテストで使用するモックを配置する
• 典型的にはgo-mockで生成したモックが配置される

model

• ドメインオブジェクトを配置する
• controllerで使用するリクエスト/レスポンスデータの構造体もここに配置する

repository

• データアクセスを抽象化するレイヤー
• DBアクセスや外部APIアクセスを実行するモジュールが配置される

usecase

• ドメインモデルを用いたビジネスロジックが記述されるレイヤー
• controllerから呼び出される
• usecaseに属するモジュールは以下の規則に従う必要がある

type ShowExampleList interface {
    Execute() error
}

type showExampleList struct {
    ...
}

func (u *showExampleList) Execute() error {
    ...
}

• (1) ひとつのユースケースを表現する
• 更にこれらのユースケースはファクトリーによってパッケージ外部に公開される

type Usecases interface {
    ShowExampleList()   ShowExampleList
    ShowExampleDetail() ShowExampleDetail
}

type usecases struct {
    ...
}

func NewUsecases() Usecases {
    return &usecases{}
}

func (u *usecases) ShowExampleList() ShowExampleList {
    return &showExampleList{}
}

func (u *usecases) ShowExampleDetail() ShowExampleDetail {
    return &ShowExampleDetail{}
}

• このようにすることで、

validator

• ドメインルールのバリデーションを行うモジュールが配置される
• modelの中に含めてもよいかもしれない
• handlerで行うバリデーションはフォーマットチェックで、usecaseで実行されるドメインルールに対するバリデーションを行う
• 例えば、DBにアクセスしてデータの存在チェックを行ったりするかもしれない

main.go

• プログラムのエントリーポイント
• 必要に応じてcmdディレクトリを作成し、その中でserver用cli用のmain.goを作成してもよい

5. ファクトリーとinterface

• テストを容易にする為に別レイヤーから呼び出されるモジュールはinterfaceを定義する
• 具体的にはusecaseとrepositoryは必ずinterfaceを定義する
• usecase

packcage

• このようにしておくことでモック化しやすくすることができ、ユニットテストが容易になる
• 典型的なAbstract Factoryパターンである

6. 各レイヤーのユニットテスト

repository