依存がなく、テスト可能であり、クリーン。

Uncle Bobのクリーンアーキテクチャの概念を読んだので、これを私はGoで実装してみたいと思います。このアーキテクチャは、自分たちの会社である Kurio – App Berita Indonesia で使っていたものに似ていますが、少し違っています。大きな違いはなく、概念は一緒なのですが、フォルダ構造が違っています。

サンプルのプロジェクトとして、記事をCRUDで管理するリポジトリを https://github.com/bxcodec/go-clean-arch にpushしてあります。

* 免責条項
ここで使われているどのライブラリあるいはフレームワークも、利用を特別推奨しているものではありませんので、ご自身あるいはサードパーティによる同じ機能のものと入れ替えることが可能です。

基本的な考え方

ご存知のように、クリーンアーキテクチャで設計する際の制約事項には以下のようなものがあります：

1. フレームワークが独立している（依存がない）こと。そのアーキテクチャがフィーチャを豊富に持つようなライブラリの存在を前提としていないこと。これにより、自分の作るシステムを限定された制約条件の中に押し込めるのではなくて、フレームワークをツールかのように扱えるようになります。

2. テスト可能であること。ビジネスルールが、UI、データベース、webサーバやその他の外部要素なしでテスト可能となっていること。

3. UIの独立。UIをシステムの残りの部分に変更を与えずに変更できること。例えば、ビジネスルールの変更を伴わずにWebのUIをCLIで置き換えられる、など。

4. データベースの独立。OracleやSQLサーバをMongo、BigTable、CouchDBやその他に交換できること。ビジネスルールがデータベースに束縛されないこと。

5. 外部エージェントから独立していること。実際のところ、あなたが記述するビジネスルールは外部の世界について全く何も分かってないでしょう。

詳しくは https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html を参照してください。

つまりこれらの制約事項に基づくのであれば、どのレイヤも独立しておりテスト可能であることが必要です。

Uncle Bobのアーキテクチャには4つのレイヤがあります：
* エンティティ
* ユースケース
* コントローラ
* フレームワークとドライバ

私のプロジェクトでも4つのレイヤを使うことにしました：
* モデル
* リポジトリ
* ユースケース
* デリバリ

モデル

Bobのエンティティと同様に全レイヤで使います。このレイヤではどんなオブジェクトのStructやMethodも保持します。例：Article, Student, Book

Structの例は以下の通りです。

全てのエンティティやモデルここに保存されることになります。

リポジトリ

リポジトリは全てのデータベースハンドラを保存します。いかなるデータベース対するものでも問い合わせやCreate、Insertといった処理がここに保存されます。このレイヤはデータベースへのCRUDのみを行います。ビジネスプロセスは発生しません。データベースに対するプレーンな関数に過ぎません。

同時に、このレイヤはアプリケーションで使用するデータベースの選択を任されています。Mysql、MongoDB、MariaDB、Postgresqiその他何であっても、ここで決定されることになります。

ORMを使用する場合は、このレイヤで入力を制御し、直接ORMサービスへ入力を引き渡します。

マイクロサービスを呼び出す場合も、ここで処理されます。他のサービスに対するHTTPのリクエストを生成し、サニタイジングを行います。このレイヤは完全にリポジトリとして動かなければなりません。全ての入力と出力データを処理し、特殊化されたロジックは入り込まないようにします。

このリポジトリレイヤは接続状態にあるデータベースや、あるいは、もしあるのならばマイクロサービスに依存します。

ユースケース

本レイヤはビジネスプロセスのハンドラとして動きます。あらゆるプロセスがここで処理されます。このレイヤがどのリポジトリレイヤを使うかを決めます。つまりデリバリレイヤへデータを提供する責務を負うことになります。データによる計算などの処理の全てがここで行われます。
ユースケースレイヤは、デリバリレイヤからのどんな入力（サニタイズ済み）にも応じ、受け取った入力をデータベースに保存したり、またはデータベースからフェッチするなどの処理を行っていきます。

ユースケースレイヤはリポジトリレイヤに依存します。

デリバリ

本レイヤはプレゼンタとして働きます。どのようにデータが提示されるかを決定します。REST API、HTMLファイル、gRPCなど、どのようなデリバリ形式にもなり得ます。
本レイヤはユーザからの入力にも応じます。入力をサニタイジングしユースケースレイヤに送ります。

サンプルのプロジェクトでは、REST APIをデリバリメソッドとして使っています。
クライアントがネットワーク上でリソースのエンドポイントを呼び出し、デリバリレイヤが入力またはリクエストを得て、それをユースケースレイヤに送ります。

本レイヤはユースケースレイヤに依存しています。

レイヤ間の通信

モデルを除いて、各レイヤはインターフェースを通して通信し合います。例えば、ユースケースレイヤにはリポジトリレイヤが必要ですが、どのように通信するのでしょうか。リポジトリは、コントラクトとなるようにインターフェースを提供し、通信するのです。

リポジトリのインターフェースの例

ユースケースレイヤは、このコントラクトを使ってリポジトリに通信します。そしてリポジトリレイヤは 必ず このインターフェースを実装し、ユースケースが使えるようにしておきます。

ユースケースのインターフェースの例

ユースケースと同じように、デリバリレイヤはこのコントラクトインターフェースを使います。そしてユースケースレイヤは必ずこのインターフェースを実装しなければいけません。

各レイヤの検証

ご存知のように、クリーンであるということは独立していることを意味します。たとえ他のレイヤが存在していなくても、各レイヤのテストが可能です。

• モデルレイヤ
  本レイヤは、何かしらの関数またはメソッドが、何かしらのstructを宣言した場合のみテストします。
  テストは容易であり、他のレイヤから独立しています。

• リポジトリ
  本レイヤのテスト手法としては、結合テストがオススメです。しかし、テストをモックで行うこともできます。私の場合はgithub.com/DATA-DOG/go-sqlmockをヘルパとして使い、MySQLのクエリのプロセスをモックしています。

• ユースケース
  本レイヤはリポジトリレイヤに依存しているため、検証にはリポジトリレイヤが必要となります。そのため、定義済みのコントラクトインターフェースを元にmockeryを使ってモックしたリポジトリのモックアップを作らなければなりません。

• デリバリ
  ユースケースがリポジトリレイヤに依存しているのと同じように、本レイヤはユースケースレイヤに依存しているため検証にはユースケースレイヤが必要となります。そしてユースケースレイヤも、定義済みのコントラクトインターフェースを元にmockeryを使ってモックしなければなりません。

私は、モックにvektra によるGoのためのmockeryを使っています。こちらは https://github.com/vektra/mockery で確認できます。

リポジトリのテスト

本レイヤのテストでは、私は前述したとおりsql-mockを使って、クエリのプロセスをモックしています。私がgithub.com/DATA-DOG/go-sqlmockで使っている方法でもいいですし、もしくは似た関数を使った方法でもテストすることが可能でしょう。

 func TestGetByID(t *testing.T) {
 db, mock, err := sqlmock.New()
 if err != nil {
 t.Fatalf(“an error ‘%s’ was not expected when opening a stub
 database connection”, err)
 }
 defer db.Close()
 rows := sqlmock.NewRows([]string{
 “id”, “title”, “content”, “updated_at”, “created_at”}).
 AddRow(1, “title 1”, “Content 1”, time.Now(), time.Now())
 query := “SELECT id,title,content,updated_at, created_at FROM
 article WHERE ID = \\?”
 mock.ExpectQuery(query).WillReturnRows(rows)
 a := articleRepo.NewMysqlArticleRepository(db)
 num := int64(1)
 anArticle, err := a.GetByID(num)
 assert.NoError(t, err)
 assert.NotNil(t, anArticle)
 }
 ```

###ユースケースのテスト

リポジトリレイヤに依存しているユースケースレイヤのテストのサンプルは以下の通りです。

<script src="https://gist.github.com/bxcodec/16ca1ee154c2b84cde44146d76955ffc.js"></script>

mockeryはリポジトリレイヤのモックアップを生成します。そのため、最初にリポジトリレイヤを完成させる必要はありません。リポジトリレイヤが実装されていなくても、先にユースケースを完成させることができます。

##デリバリのテスト

デリバリのテスト方法は、データを送る方法によって左右されます。HTTPのREST APIを使っている場合は、Goの組み込みパッケージであるhttptestパッケージを使うことができます。

ユースケースに依存しているため、ユースケースのモックが必要です。リポジトリと同じように、私はmockeryを使ってユースケースをモックしてデリバリの検証を行っています。

func TestGetByID(t *testing.T) {
var mockArticle models.Article
err := faker.FakeData(&mockArticle)
assert.NoError(t, err)
mockUCase := new(mocks.ArticleUsecase)
num := int(mockArticle.ID)
mockUCase.On(“GetByID”, int64(num)).Return(&mockArticle, nil)
e := echo.New()
req, err := http.NewRequest(echo.GET, “/article/” +
strconv.Itoa(int(num)), strings.NewReader(“”))
assert.NoError(t, err)
rec := httptest.NewRecorder()
c := e.NewContext(req, rec)
c.SetPath(“article/:id”)
c.SetParamNames(“id”)
c.SetParamValues(strconv.Itoa(num))
handler:= articleHttp.ArticleHandler{
AUsecase: mockUCase,
Helper: httpHelper.HttpHelper{}
}
handler.GetByID(c)
assert.Equal(t, http.StatusOK, rec.Code)
mockUCase.AssertCalled(t, “GetByID”, int64(num))
}
“`

最終出力とマージ

全てのレイヤが完成し、テストを終えたら、ルートプロジェクト内のmain.goにある1つのシステムにマージします。ここで定義を行い、その環境に必要なものを生成し、全てのレイヤを1つにマージします。

例として私のmain.goをご覧ください。

全てのレイヤが依存関係によって1つにマージされているのが分かります。

まとめ

• 端的に図で表すと以下のようになります。

• このプロジェクトで使われているライブラリは全て、あなたが使っているライブラリに置き換える可能です。クリーンアーキテクチャで重要な点は、どんなライブラリを使っていたとしても、アーキテクチャがクリーンであれば、テストが可能であり独立しているということです。

• 本稿では、私のプロジェクトの組み立て方法について記述しました。反論や同意、または本稿を改善するための意見があればコメントを残し、シェアしてください。

サンプルプロジェクト

サンプルプロジェクトは https://github.com/bxcodec/go-clean-arch で確認できます。

本プロジェクトに使ったライブラリは以下のとおりです：

• Glide：パッケージの管理
• github.com/DATA-DOG/go-sqlmockのgo-sqlmock
• Testify：テスト環境
• Echo Labstack（Go言語のWebフレームワーク）：デリバリレイヤ
• Viper：環境設定

クリーンアーキテクチャに関する参考記事：

• https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html

• http://manuel.kiessling.net/2012/09/28/applying-the-clean-architecture-to-go-applications/ ：Go言語による別のクリーンアーキテクチャ

本稿で説明が足りず、質問がある場合や、もっと説明が必要な場合などは、 Linkedin か メール でご連絡ください。お読みいただきありがとうございました。