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
の登場人物を採用するのではなく、
別のアーキテクチャと組み合わせたり、役割を纏めたりといったことをして、作るアプリケーション応じて最適化することで、
粒度を最適化した作りやすくメンテナンス性のある構成を実現できると考えました。