DDD+CQRSを.NETでやるならReactivePropertyが便利なのでは、という話

お勉強でTodoListをDDD的流れで作成していたらReactivePropertyが良かったので紹介して見ようと思いました。
以下、作成記録です。

#TL;DR
* ドメインイベントのメッセージ基盤には[MessageBroker][]で必要十分。
* CQRSのコマンド部は[ReactiveCommand][]を継承して実装すれば便利なのでは。

どちらも.NET Standardでも使えるからドメイン層を使い回し可能。
オレオレで作るよりかは良いかと。

#ステークホルダーからの要件っぽい内容を定義しておく
* TodoListを作成したい。
* ひとつのTodoをタスクとして管理する。
* 管理する内容はタイトルと説明とそのTodoの状態。
* 状態は2値ではなく実行中を含めた3値としたい。
* タスクのリストを表示して、ひとつを選択すると詳細な情報が表示されるようにしたい。
* タスクを新規に作成するとそのタスクの詳細な情報を入力できるようにしたい。

#要件っぽい内容を基にユビキタス言語の抽出とワイヤーフレームを提示してみる
##ユビキタス言語一覧
| 項目 | 英語 | 説明 |
|:-:|:-:|:-:|
| タスク  | Task  | Todo１件を表す |
| タイトル  | Title  | タスクのタイトル  |
| 説明  | Explain  |  タスクの内容説明 |
| 状態 | Status | タスクの状態を表す。3値。Ready, Doing, Done とする |
| タスクリスト  | Tasks  |  タスクを束ねたリスト |
| (タスク)ひとつを選択すると | SelectedTask | ドメインイベント？画面上の話だからアプリケーション層で取り扱うかも |
| タスクを新規に作成すると | AddedTask | ドメインイベント。他にも拡張ポイントとして編集されたときとか、削除されたときとかのドメインイベントを用意する必要あるかも。 |
| タスクを新規に作成する | AddTaskCommand | コマンド。他にも編集とか削除とかのコマンドが増えるはず。 |
| 入力画面 | Input View | タスクを新規に作成するときにここにタイトルを入力する。ボタンでタスク作成にするか、Enter検知でタスク作成にするか |
| リスト画面 | List View | タスクのリストを列挙する。新規に作成されたタスクはリストの下部に追加？上部に追加？ |
| 詳細画面 | Detail View | タスクの内容を表示する。その場で編集もできるようにしたい。

##ワイヤーフレーム
![wireframe.png](https://qiita-image-store.s3.amazonaws.com/0/109302/7c9531d3-9b9a-a37c-e7a5-a228eef9a3b8.png)

実際の開発だとここをステークホルダーとがっつり詰めないといけない気がする。

#文章をUML化
とりあえず上記内容でなんとなく固まったとして、文章だと解りづらい点をユビキタス言語にのっとって図解しとく。

##クラス図
![LO_1QWCX48RlynH3ZYtx0hA475nAeAUcBo1LWjHrIsQ4bjHtByPPgoUTRtu-_ZaHcnkdDS17C4JuRkZphF4EppZFLyV78tghy2Lv2tdFU0vkY70X2eblFbvRRld-2iR78Uagwx8kfXKlR3ZHKhvtU7F6_e3UobvlqUr2IGq-UY3L2I23vBPfwdXtu60uQoLN_yDwegfFXvUzlNowrMKe0XcAi.png](https://qiita-image-store.s3.amazonaws.com/0/109302/bef485ce-1008-81d7-d1cb-8e9adfde0c73.png)

ドメインはこんなもん。Taskを集約ルートとして識別するためにTaskIDを用意した。Tasksはファーストクラスコレクションとして用意。その他は値オブジェクト。必要になれば副作用のないメソッドを増やしていく。

##パッケージ図
![XPF13X8n48RlVOgz6tW0GWZ4XMGJYOaGByP3tGxOq6tNTXP33EzktQauEsxqj9dl_sVwToZRX3hYq3c5eQymL5y2OkWgOoEqQ8DNgjVjJL-XEchhg_Nw49o1kDbKFrxAEvjmghHEfpJoZnQ-Y_8O33Z6gFwjLejFNwqnu3_7XMYPLDp7nZnVgHhV3tEnI2YvU4rpEIH0kemckgRbtqwPhWRKr.png](https://qiita-image-store.s3.amazonaws.com/0/109302/66824c2b-ab86-a779-0ef5-9ddb9e1c65b2.png)

.NET的なプロジェクトの分割も図解。
Domainだけを参照するように依存関係逆転の原則(DIP)で作っておく。
ListViewにタスク一覧を表示するときにはStatusとTitleしか必要ないのでCQRS的にDTOとクエリを用意しておく。
画面に表示する内容はアプリケーションの事情なので置き場所はAppServiceにしてみた。
画面上でタスクが選択されたというイベントもアプリケーションの事情だと思ったのでAppServiceに置いた。

##シーケンス図
![XOzB2i8m48RtEKMMBTWBY9HggT15HSGBn6RGqZnA7bPlxrHHD2cupEJxlvc_i8uPvwKWjHgyQpG7GRESraTc-r9BoHJVijPfSwTBMXfW3jQSV_qcEnYdPqhcCgZwnT6YO7o75gz.png](https://qiita-image-store.s3.amazonaws.com/0/109302/4be43e2d-87a1-9b4e-2588-ddebb36e28bb.png)

![VO-n2i8m54NtV4L67PeFa52gu21O47HrI7oNDZHj8E_5xpUJGuREbtCETs1nMSeQrJsmZ8aGTTVhsmXcD-6IquAiJ_fPF7zoyB1d8j3ByNBzOfF-K0bCJa1wXSo9Zgg1g-xlLiQ.png](https://qiita-image-store.s3.amazonaws.com/0/109302/82b78915-4e6b-b0cc-4ba3-c0e53d27c673.png)

Taskを追加するときのシーケンスを作成。
ステートレスなインスタンスはIoCコンテナを通してコンストラクタで注入しておく。

ここでやっとタイトルの話。
AddTaskCommandは[ReactiveCommand<T>][ReactiveCommand]を継承し、Executeメソッドを作成して最後にbase.Execute(T parameter)を実行する。
こうすれば戻り値をSubscribeできるし、必要であれば複数コマンドの直列処理も並列処理も楽。
ドメインイベントに関しては[IMessageBroker][MessageBroker]を使った単純なPubSub。
購読解除も他のIDisposableと一緒に[CompositeDisposable](https://github.com/Reactive-Extensions/rx.disposables/blob/master/doc/compositedisposable.md)に追加しておけば解除漏れの心配もなし。

#実装
##成果物
[ToDoListSample](https://github.com/kwhrkzk/ToDoListSample)

##使用したライブラリ/フレームワーク
* Prism 7.1.0.431
* ReactiveProperty 5.3.0

#感想
* ReactivePropertyについては[TL;DR](TL;DR)に書いた。
* そもそもDDD的になっているか？今後新たな要件が増えたとしても変更は局所的になる気はする。
* CQRSもこんな感じで良いのかしらん。クエリの方はさっくり理解できた気がするけど、コマンドの方はコマンドバス(コマンドハンドラ？)を用意してそこにコマンドを蓄えてから実行するのが正解なのだろうか。
* イベントソーシングはパス。
* ドメイン層に置くべき処理(イベント)なのかアプリケーション層に置くべき処理(イベント)なのかの判断が難しい。ドメイン層より外側の層が全て入れ替わっても業務知識がこぼれなければ良いと思っているが。


[ReactiveCommand]:https://github.com/runceel/ReactiveProperty/blob/master/Source/ReactiveProperty.NETStandard/ReactiveCommand.cs
[MessageBroker]:https://github.com/runceel/ReactiveProperty/blob/master/Source/ReactiveProperty.NETStandard/Notifiers/MessageBroker.cs