mike-neckのブログ

Java or Groovy or Swift or Golang

JSUG勉強会 - 「Spring Boot ベースの DDD サンプル徹底解説」に行ってきた話

JSUG 勉強会 Spring Boot ベースの DDD サンプル徹底解説 に行ってきました。

jsug.doorkeeper.jp

DDD については、考え方的にはわかっているところもあるのですが、実際のコードを見てがっかりしたり、コードの例が理想的すぎて現実味がないといったことから、理解から遠いところにある印象があったので、この勉強会のアイデアがあると増田さんがツイートしていたときから興味を持っていました。しかし、最近 jsugjjug の勉強会の募集を開始した旨のメール/ツイートを見逃してしまうことがあり(ここ2〜3回見逃している)、この勉強会もその一つで実際に見逃していて、申し込んだときにはキャンセル待ちが発生していました。前世での徳が高かったのか、前日の夕方くらいになって参加できることになり、キャンセルしていただいた方には非常に感謝しております。

f:id:mike_neck:20180802004547p:plain


さて、当日のツイートなどについては有志の手により(僕が作りました)togetter にまとめられています。

togetter.com

また、増田さんがツイートしていましたが、設計のガイドラインがこちらにまとめられています。

github.com

また皆で鑑賞したコードがこちら。

github.com

その他、勉強会の内容についてのブログは、勉強会終了直後からいくつか書かれている方がいらっしゃるようです。

omix222.hatenablog.com

takeda-san.hatenablog.com


ここからは、僕の感想とか、僕が質問した内容とかのまとめ。

モデルクラスの「それゲッターじゃん」問題。

モデルクラスの実装については、普段書いているコードとだいたい同じような感じでした。質問で「それゲッターじゃん」という指摘がありましたが、元々は何かしらの計算して出力した値だったかもしれないけど、リファクタリング等でこの今はこの形になっているよという考えればよいのかと思っています。

僕は「ゲッターを書かない」というのは、モデルクラスとは名ばかりの値とゲッターだけしかないクラスを作ってしまうと、ロジックが様々なサービスクラス的なものに分散してしまうし、サービスクラスはレポジトリーなどの入出力も関与するために純粋にロジックだけをテストするようなこともできなくなるといったデメリットが多くなってしまうため、純粋なロジック部分はモデルの中に閉じ込めるという意味合いの言葉なのかと理解しています。

なお、これを書いている時に設計ガイドラインの「ドメインに閉じた型とドメインに閉じていない型」の二種類を区別していて、「ドメインに閉じていない型」にはプログラミングの関心事とドメインの関心事が混ざっているとの記述を発見しました。この「ドメインに閉じていない型」の方ではゲッターに相当するメソッドないしはフィールドアクセスなどが行われているだろうと想像します。(「〜に閉じた/閉じてない」的な用語を何かで見かけたような記憶…)

コーディネータークラス

お仕事のコードには、サービスクラスという名前のレポジトリー + (一般的な意味での)サービスクラスの構成のクラスがあり(なんとかしたいと思っている)、そのサービスクラスを利用するクラスがあって、それをサービスクラスと名前がつけられていて非常に違和感を感じていたのですが、コーディネーターという名前があるんですね。よい名前を知りました。今後はコーディネーターという名前をつけていきたいと思います。

jig

最近読んだ本に「進化的アーキテクチャー」なる本があったのですが、その中でもパッケージの依存関係を適応度関数として利用するみたいな記述があり、パッケージの依存性の管理(つまり複雑になっていると進化を阻害する)を簡単にするツールとして便利そうだと思いました。また、皆が質問している裏でいろふさんがリファクタリングをはじめて、その際にgradle の jig タスクを頻繁に回して依存関係を確認していたのは印象的でした。


以上、僕より先にブログ書いた方のものよりも少量ですが、自分なりの感想をまとめてみました。