CleanArchitecture的な構成のGo API サーバー サンプルコード(echo, wire利用)

はじめに

CleanArchitecture的なパッケージ構成に照準を合わせてGoのREST API Serverの実装をしてみる。
更にGoのweb framework echoとDI code generatorであるwireを組み込む。

excuse

この構成で本番稼働実績が有る訳ではなく、まずは叩き台的に考えてみました。
まだ改善の余地は有りそうです。

実装リポジトリ

＊利用方法はREADMEを参照。

ディレクトリ構成

├── cmd
│   └── server
├── db
├── domain
│   ├── model
│   └── repository
├── handler
├── infra
│   └── mysql
├── response
├── router
└── usecase

cmd

sever起動のmainファイル。

db

dbへの接続情報。
migration情報もここに置くかもしれない。
infraに置いても良いかもしれない。

domain/model

単一エンティティのドメインロジックはこちらに記述。

domain/repository

永続化情報のインターフェイス。

handler

echoのエンドポイント処理から呼ばれるハンドラ郡。
ここでwireを使いDependeny Injectionする構成とした。

infra

永続化処理の実装詳細。

response

要件に応じてこちらでレスポンスフォーマットを決める。

router

echoのルーティング エンドポイント定義を集約する。

usecase

ドメインロジック以外のアプリケーションロジックをこちらに記述。

更に実装する場合の検討ポイント

DBトランザクションどこに置く？

usecase内でbeginして引数にDBセッション持ち回るくらいが収まりが良さそうな気がしている。
(infraに永続化実装詳細が収まってないが、、)

レイヤーが分離してない？

もっと厳密にやるならinfraで構造体に別途DBタグを用意してmodelと相互変換してもよさそうだが出来ればmodel structをそのまま持ち回って手数を減らしたい。

sqlでtable joinとかしたら？

domain/serviceにてネストした構造体を用意してinfraでクエリ結果を受け取れば良い？

type (
    Joined struct {
        Example
        Example2
    }
)

参考

Clean Architecture 達人に学ぶソフトウェアの構造と設計
https://github.com/golang-standards/project-layout
https://future-architect.github.io/articles/20200528/