はじめに

この記事は、以前の記事の続きです。
GoogleSamples（android-architecture）を斜め読みして筆者が印象に残った内容を書きます。

バックナンバー

1. Model-View-Presenter(MVP)+αを読んでみる
 2. Clean Architectureを読んでみる
 3. MVVM & DataBindingを読んでみる
 4. MVVM & LiveDataを読んでみる

MVP - Clean Architecture

「Clean Architecture」のキモとして「UseCaseパターン」が使われています。
MVPは以前の記事と同じなので、異なる部分だけ要約します。

パッケージ構成

com.example.(...).xxx;
com.example.(...).xxx.domain;
com.example.(...).xxx.domain.model;
com.example.(...).xxx.domain.usecase;
...
domain パッケージにビジネスロジックを集約する感じ。

google samplesのユースケースは通信を主体にしたロジックの様なので、RequestValue, ResponseValueというinner classを定義しています。
汎用的に考えると、各ユースケースの in / out のベースクラスを定義して高い抽象化を実現したいのだと思います。

UseCase

public abstract class UseCase<Q extends UseCase.RequestValues, P extends UseCase.ResponseValue> {
    public interface RequestValues { /* 空定義 */}
    public interface ResponseValue {/* 空定義 */}
    public interface UseCaseCallback<R> {
        void onSuccess(R response);
        void onError();
    }
}

ユースケースの対象となるモデルを定義し、ユースケース毎にモデルの処理を定義していきます。
サンプルコードでは、モデルを「Task（やるべき作業）」として、ユースケースは「Get, Add, Complete」等としています。

Task + Get = GetTask　→　タスクを取得する
Task + Add = AddTask　→　タスクを追加する
Task + Complete = CompleteTask　→　タスクが完了した

分かりやすいですね。
車なら「モデル：Car、ユースケース：Ignite（エンジン点火）、Run（走る）、Idling（アイドリング）、Fueling（給油）」
人なら「モデル：Person、ユースケース：Sleep（寝る）、Eat（食べる）、Work（働く）、Vacation（休暇）」

プログラムとしては、以下の構造になっています。分かりやすいよう、独自のコードで表現します。

モデル

package com.example.(...).xxx.model;
public class Car {}

ユースケースの実態クラス

package com.example.(...).xxx.usecase;
public class IgniteCar extends UseCase<IgniteCar.InputValues, IgniteCar.OutputValue> {
    public static final class InputValues implements UseCase.InputValues {...}
    public static final class OutputValue implements UseCase.OutputValue {...}
}

いかがでしたでしょうか

UseCaseパターンはビジネスとの親和性が高く、ビジネスの良し悪しがパッケージ / クラス構成の良し悪しに出てきそうですね。
（ソースや設計がイケてない　→　ビジネスモデルがイケてない！？）