クライアント、サーバー それぞれから視点で見た Clean Architecture

2019/06/13追記

本記事の内容から考え方を改めました。
新しい考え方は【改訂版】クライアント、サーバー それぞれから視点で見た Clean Architecture にまとめましたので、こちらを見ていただければと思います。

一応、比較の意味を込めて本記事は残させていただきます。

TL;DR

クライアントアプリ、サーバーアプリ両方を作ってみた上で、Clean Architecture とは何かを改めて考えて自分の中でまとめてみました。

登場するレイヤーや役割は、 こちら を参考にさせて頂きました。
なお、 View が、 ユーザーに対しての表示 の役割と、 ユーザーからの入力 の役割を兼ねているので、
入力側の役割を Action と別途名前を付けて分割させて頂きました。

Action

• View が、 ユーザーに対しての表示 の役割と、 ユーザーからの入力 の役割を兼ねているので、入力側の役割を別途名前を付けて分割しています。

サーバーサイドから見た Clean Architecture

Action

• リクエストのルーティングだったり、パラメータを分解して引数に展開したりする
• 主に Web Framework だったり、gRPCのサーバー側として隠蔽されることが多いのでは

UseCase

• リクエストのバリデーション やパラメータに応じた分岐だったりのビジネスロジックに対応する

Repository

• UseCase が Entity を利用する際に、 DataStore の どこから を隠蔽し、取得先が変わっても UseCase への影響を極力減らすためのI/F
• DataStore を Stub などに差し替えたりするのにも使える
• とりあえず簡単に作りたい場合や、継続してメンテがない場合などは、直接 DataStore を扱った方が早く作れるので、プロジェクトに応じてここまでやるかは考えた方が良いところ
  • DataStore を別のものに差し替えたいといったときに I/F を一切変えずに作るは割と難しく、先を見通す力や経験だったりが必要。

DataStore

• DB や ファイルシステム、クラウドサービス などとデータをやり取りする
• ORM や HttpClient、gRPC のクライアント側として薄くラップして扱われることが多いかな

Entity

• DataStore でやり取りするデータの構造
• 使うライブラリによっては、 カラム名のマッピングや、DB のテーブル名を書いたりといったことを書いたりする

Translator

• レスポンスの要件によって、複数の Entity をマージして、サービス特有の構造（Model）に変換する処理記述
• 最初は Entity をそのまま返せば楽だからと作りがちだが、運用を開始したあとにクライアントが使いづらいとか、リクエストの最適化から作らざるを得ないことが殆どなので、あるものとして考えた方が無難

View

• Translator から渡された Model を JSONやHTMLなどに変換してクライアントに返す
• 主に Web Framework だったり、gRPCのサーバー側として隠蔽されることが多い
• サーバ側で View と呼ぶのかは微妙ですが、要クライントに向けた Presentation 方法

クライアントサイドから見た Clean Architecture

ここでいうクライアントとは iOS や Android アプリなどを指します。
ここでは別途 MVVM も適用しているとします。

Action

• ボタンやテキストなど各コントロールからユーザー操作を受け付ける部分
• iOS だと ViewController に該当

UseCase

• 入力がユーザー操作だったりするくらいで、基本的な役割はサーバーサイドと変わらない

Repository / DataStore / Entity

• 基本サーバーサイドと役割は変わらない

Translator

• View などユーザーへの見せ方の要件に応じて適宜 Entity を変換する

View

• ユーザーの目に見える形で表示を担当する部分
• iOS だと ViewController に該当

まとめ

Clean Architecture は、アプリケーションを構成する上で必要な役割を、最大限（言い過ぎかもしれませんが）細分化した考え方であると捉えます。
そのため、作るアプリケーションの構成や利用するライブラリ、プラットフォームに依存する部分などに応じて、
そっくりそのまま Clean Architecture の登場人物を採用するのではなく、
別のアーキテクチャと組み合わせたり、役割を纏めたりといったことをして、作るアプリケーション応じて最適化することで、
粒度を最適化した作りやすくメンテナンス性のある構成を実現できると考えました。