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

JSUG勉強会 2017年その3 ~ ドメイン駆動設計 powered by Spring に行ってきた

JSUG勉強会 2017年その3 に行ってきました。簡単に所感をまとめます。

jsug.doorkeeper.jp

今回のテーマはドメイン駆動設計と Spring です。資料はこちら。

www.slideshare.net

  • ドメインロジックに集中する
  • Spring Frameworkドメインモデル以外のことをすべて用意するフレームワーク
  • ドメインモデルは振る舞いとデータの両方を組み込んだオブジェクトモデル
    • ドメインロジックをオブジェクトで表現する
    • データを持つクラスが唯一ロジックを持つ
    • 変更容易性を向上する
  • ドメインロジックをモジュール化する場合はドメインオブジェクトとして部品化する
  • ドメインロジックを自己文書化する
    • ドメインオブジェクトを使う他のレイヤのコードに自己文書化が波及する
    • 引数や戻り値の型で何をしているかが分かる
  • ドメインを隔離する
  • ドメインオブジェクトに getter/setter を書かない
    • DirectFieldAccess (↓のスライドを参照)

speakerdeck.com

  • Service クラスに @Validated を付ける
    • メソッドの引数や戻り値にバリデーションができる
    • 契約による設計 (事前条件/事後条件) の考え方が実現できる
  • モデルの一部としてインタフェースを宣言する
    • Repository インタフェース
    • インタフェースで実装を分離する
    • データベースの都合をドメインオブジェクトに持ち込まない
    • データソース層がドメインモデルに依存する (依存関係が逆転する)

今回、Spring の3層のレイヤー (@Controller, @Service, @Repository) に沿って話をされていて、自分にとっては理解し易くとても参考になるものでした。Sprint 特有の話ではあったかと思いますが、割と難しく考えがちなドメイン駆動設計を身近なものとして考えられました。

一気に全体を書き換えるのではなく、まずはトランザクションスクリプトの中に埋め込まれているドメインロジックをドメインオブジェクトとして分離するところからスタートすればよさそうです。要するにリファクタリングですね。

ところで、DirectFieldAccess を初めて知りました。あと、クラスに @Validated を付けられるんですね…。これも初めて知りました。契約による設計を割とシンプルに実装できそうで便利かも。あとで試してみよう。