What is "Domain Object"?
アプリケーションの中で、単独の機能として独立した部品のことをDomain Objectという。
ここでいうDomain Objectはとても広い意味で使われている。
例えばこのDomain Objectは以下のような様々な粒度の抽象度を持っている。
1. ビジネスレベル（Application Service）
- 銀行システム、航空券予約システム
2. 機能レベル（Component）
- 為替計算機能、消費税計算機能
3. さらに細かいレベル（Value Object, Copied Value, Immutable Value）
- 型ではなく、状態に注目されるものたち
- 日付、消費税率
実装の注意点
- 各オブジェクト感はインターフェースを介して実装する。
- オブジェクトのクライアントが実装の内容ではなく、Contractにのみ関心を持つことで、別々に開発することが可能になる。
- 個々のオブジェクトを独立させる程度は、以下の２点によって決まる。
- そのオブジェクトの抽象度
- そのオブジェクトの変更頻度
ジモティーで考えると？
開発のセオリー？は異なるオブジェクト間のコミュニケーションには間にinterfaceを挟むことのような気がして来ました。
（なんども develop and evolve independentlyという記述が出て来ます。）
ただinterfaceを挟むことはファイル数が多くなったりして、いいことばかりじゃないです。
この章でも言われているように、interfaceを挟むポイントは、オブジェクトの抽象度が高い場合、またはオブジェクトの実装に変更が加えられる頻度が高い場合です。
例えば、ジモティーのAndroidはActivity（View）とPresenter（画面の表示のための処理を一括管理している。データの取得、ロジック、データの整形など）の間にinterfaceを挟んでいます。
しかし、Presenterとinteractor（ロジック）の間にはinterfaceがありません。
ここにもinterfaceがあってもいいのかもしれないと思いました。理由は以下の２点です。
1. PresenterはView層で、interfaceはDomain層だから。二つの間に層を区切るinterfaceが必要。二つの層の間を意識せずに直接実装を参照できるのはアーキテクチャとしてはだめなきがする。（実際、repositoryは異なる層の間を埋めあわせるinterfaceとして定義されている）
2. interactorはまだ育てている途中で、かなり変化が激しい。だからPresenterはinteractorの実装に依存させないで、コントラクトに依存させるようにした方が安定しそう。開発者としても影響範囲の切り分けに自信を持てる気がする。
以上のような理由もあって、UseCaseはその役目を担うことになるのかなと思っています。