このまとめとは

PDSを意識した結果をパターン化されたFlux,MVVM,MVPなどを当てはめて開発されているということが勉強会とかでよく見るようになり, 最近ようやくPDS（Presentation Domain Separation）を理解して,アプリを作る際に大枠で反映できてきてると思い始めたのでそれについてどう考えているかのまとめ.^{1, 2}

各種の定義

プレゼンテーション（Presentation)

ユーザー、もしくは別のシステムに対して,自身のドメインに対する入出力を請け負う部分と定義する. Androidで言えば、ユーザーに対するシステムの出力はActivityで画面を作り,各システムの状態をViewを用いてユーザーに対して状態を理解できる形で見せること, ユーザーからの入力は,表示しているButton, EditTextなどからの入力を受けとることとも表現できる.

ドメイン（Domain)

入力を受けた際にその入力に対する適切な計算を行った結果を出力する部分と定義する.

ここでいう適切な計算とは

簡単なところでは, 電卓であるなら四則演算.
レジのシステムなら, バーコードの画像を解析して十数桁の文字列を出力する処理, その十数桁の文字列を入力として商品名,価格などの情報を検索し出力する処理などなど

こうしてプレゼンテーション,ドメインを定義するとそれらを橋渡しするのが必要なのが見えてくる.
橋渡しの仕方で,MVP,MVVM,Fluxなどなどと名前がつけられている.

橋渡しの仕方

MVVM

M: Model（ドメイン）
V: View（プレゼンテーション）
VM: ViewModel（橋渡し）
MVVMではドメインとプレゼンテーションの橋渡しをViewModelと名付けられている部分が行う.
なのでViewModelは,プレゼンテーション側でのユーザー視点でのイベントをドメイン側に通知するためのIFを持ち、その入力に対するドメインの出力を受け取る形を取っている.
重要なのがドメインが持つ状態は,Mに持たせその変化をMVで監視するという形を取る.ViewはMVが持つ状態を参照して構築するようにするがMVが持つのはあくまでドメインの状態のコピーであるところ.
このあたりをうまく実装するのにドメインの状態をRxにあるBehaviorSubjectなどを用いて簡単に監視できるようにしておく.

Flux

FluxはView側にとてもよった形をしており,MV*系とは少し異なると思っている.
Fluxは, Actionにドメインの処理をまとめがちになる³が,ActionはあくまでドメインとのIFに終始するといい感じになる.
ドメインから戻される処理をStoreに反映し,その変更をもってViewが構築される形を取るようにする.

まとめ

MVVMなどはPDSをパターン化したもの. ドメインの設計方法ではない.

宣伝

この記事は下のアプリを作る際に決めた設計方針です. 言わずもがなKotlinで書かれており, またDaggerの代わりにKodein使ってみたり新しめなことを試している感じになっています. 参考になったりしたらstarほしい https://github.com/ttymsd/ConnpassAndroid

余談

Android3.xが発表されたころに出てきたFragmentの思想は,同じ見た目を提供するものであるなら同じドメインに関連するであろうとのもと、プレゼンテーションとドメインをActivityから切り出すためのコンポーネントと思っている. PDSに関心がより始めると、FragmentとCustomViewの違いは些細なことと思い,Fragmentは使わないことを方針にしている.

1: エリックエヴァンスのドメイン駆動設計とかは持っているが未だに最後まで読んでない
2: ちなみに去年はFluxを勉強してたのでそれについてまとめていた.（順序が逆だが）
3: 各種API叩いてまとめるActionとか・・・

ぼんぼるひとのメモ帳

最近の設計思想