GCSのCLIツールをGoとオニオンアーキテクチャで作ってみた

リポジトリはこちら

https://github.com/KamabokoHouse/go-storage

機能的を説明すると引数で受け取ったバケットのオブジェクトを一覧表示するというCLIツールです。

アーキテクチャ

ディレクトリは以下のようになっています。 (全部は説明しないので特徴的なところだけ)

go/go-storage/
├── commands
│   ├── application
│   │   ├── list.go
│   │   └── root.go
│   ├── domain
│   │   ├── exit.go
│   │   └── list
│   │       └── service.go
│   └── infrastructure
│       └── gcs.go
└── main.go

• main.go

application内のUseCaseを呼び出します。 起動時なのでroot.goですね。

• application/root.go

CLIツールのrootコマンドの定義を行なっています。
rootコマンドを実行すること自体がUseCaseなのでdomainに分離せず、直接書いています。

• application/list.go

サブコマンドの定義を行なっています。
ここではUseCaseの処理手順の定義だけを行い、処理自体はdomain層に移譲しています.

• domain/list/service.go

サブコマンド list の処理内容を定義します。
処理単位でメソッドを定義しています。 また、domain層とinterface層ではinterfaceの定義を必須としており、層を跨いだ依存を無くしています。
これでMockも作りやすいですしね。　　

• infrastructure/gcs.go

実際に外部のGCSと処理通信を行う層です。
それぞれのユニーク性を持たせると無作為にメソッドが増えていくためparameterは外部から注入する形にしています。
ここではGetのみですが、状況に応じてGetByQueryなどを追加するといいでしょう。

余談ですがAPIやコンポーネントを作成するときの注意点として、パラメーターが追加される毎に対象は絞られていかなければなりません。　　 もしこの原則に反するようになっていたら設計がおかしくなっているので見直すようにしたいですね。　　

ここ以外の注意点としては、エラーを各層で握り潰さずmainまで必ず返すことです。
エラー処理の処理方法を属人化させないようにします。

本当はDIやテストも実装したかったのですがとりあえずここまでです。