読者です 読者をやめる 読者になる 読者になる

by shigemk2

当面は技術的なことしか書かない

まとめ Scalaでドメイン駆動設計に真正面から取り組んだ話 #ScalaMatsuri #sm_c

Scala

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はなぜなのか ずっと悩み続けてる