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