MOTEXのひと
DDDのほん
DDDって難しいの？
- DDDの本は設計思想がごちゃってて、実践ドメイン駆動設計
- 読んで、いざやってみよう！ってなったときが圧倒的にしんどい
Layered Architecture
DDD本の600ページの60ページのところ
レイヤーの責務を明確
ドメインの隔離
ユーザーに情報を隔離する
- MVCのすべてがユーザーのレイヤー
- アプリケーションのレイヤー
- インフラのレイヤー
壁
どうやって実装するんだい？
ViewModelはMVVMパターン
Form→ViewModel→Entity→SQLという流れ
実装→レビュー
- ロジックとしてドメインに必要な物は外に出さない
- 分析モデリングをイベントとして用意する
シーケンス図を書いて、処理の順番を追っかける
レイヤーの責務はごちゃりがちなので、レビューと分析モデリングをやるのが肝要
曲者のサービス(3つのレイヤー)
- アプリケーション
- ドメイン
- インフラストラクチャ
- 処理が追いつかない
サービスの責務 ドメインのロジックはテンポラリであることを強調してリファクタする
スクラムとの相性は良い。リファクタリングする時間をもうける
ドメインを隔離することがDDDの考え方の一つ
- 責務をわかりやすくする
- このロジックがこの場所にあるのはいいのか悪いのか
- 責務は分離するけどコンバージョン処理は多いな
CQRS
- Command Query Responsibility Seperation
- Query Model
- 処理をシンプルにする
- Command Model
- 従来のアーキでやるべきじゃないかなって
- Command Modelは少なめ
- クエリとして分離するぶぶんは分離して、シンプルなものはシンプルにつくる
is-a Root Entity
http://masuda220.jugem.jp/?eid=315
- 親が子の責務を知っているのはおかしいのではないか
- いいんじゃないでしょうか
- サービスが知っているパターンを採用する
メッセージ
- Javaだと例外発生させたらいいんじゃないのかっていう風潮
- Scalaでは何か起きた時のメッセージをいろいろ考える必要があると思われる
- Low Layer
- 復旧不可能なエラーはユーザーに見せたくないので、ログに出して終わるようにしたい
- 処理をするために何が出来るか出来ないかを判断したい
- なんらかのメッセージを返す実装をどうするかっていうのを話した
- Validation Scalaz
エラー時のメッセージをStack
validationはアプリカティブ ちょいちょいscalaz使ってる メッセージのやり方を考えてる stackするならvalidation
まとめ
scala難しい 悪戦苦闘してる この上dddはさらにしんどい このしんどさをシェアして一緒に解決したい。
質疑
case classはなぜなのか ずっと悩み続けてる
