Doma勉強会
Doma勉強会に行ってきた。具体的にはこれ。
資料はこれ
メモから
- View層までDomaのエンティティやドメインオブジェクトを持ち込む?
- Publicフィールド使うほうが多い?(Beanにしないことが多い?)
- Domaの設計思想的にあまりサロゲートキーは使わない(使う必要がない?)
- Batch用ConfigとAppServer用Config、両方で使えるDaoって作れるの?
- 使えるよ。DaoにConfig受け取る引数がある
- 複数DBとかもConfig工夫したらいけそうですね。
- 複合主キーをつけるときは @Id を複数につける
- 複合主キーに何か意味があるのかな。@Update時にうまいこと使ってくれる?
- 使ってくれる
- Lombokとの対応状況現状
- 問題はあるけど結構共存できるよとのこと
- 識者の意見
Doma側の Immutable Entity のコンストラクタのチェックを設定か何かで off にできれば Lombok との組み合わせも問題ないかもしれない。(要検証) #kanjava
— がくぞ (@gakuzzzz) February 13, 2016
- 問題はあるけど結構共存できるよとのこと
- JAX-RSとの併用について
- jaxbのXmlAdapter 書けば jackson もそれを使ってくれるのでエエカンジとのこと。
- ただし、ドメインオブジェクト分の XmlAdapter 書くのはだるいので APT プロセッサーを書いているとのこと。
- github.com
- ダイアレクトはページング時に使われるのが代表的な使われ方
- 1フィールド1カラムが原則
所感
Java のようにあまり高機能でない静的型の言語でORMでいい感じにインピーダンスミスマッチを解消するって言うのはなかなかうまく行かない場合が多いなぁと思っている。SELECT文の結果というのは型がある。なのでSELECT句が動的に変わる場合(JOINとかだね)というのは静的型ではどうやったってミスマッチを吸収できない。
HibernateやJPAはSELECT句とEntityをマッピングするわけではなくテーブルとEntityをマッピングするので、テーブル定義とSELECT句が一致する場合は問題ないのだけれども、一致しない場合に途端に辛いことになってくる。
Domaの場合、そもそも ORM とも言ってないし結果セットをEntityにしてくれるだけというシンプルさがある。そしてSQLを書かせる代わりにメソッドの情報として利用しているのでコンパイル時に強力に型チェックしてくれる。みたいなのはやっぱりいいなぁと思う。
ひとつだけ気になっているのはDomaのいろいろ割り切った故のほぼ完成しちゃっている感。うらがみさんにも「今後のロードマップとかあるんですかね?」って聞こうと思ってたけど忘れてた。完成しちゃってメンテナンスフェイズとかに入ると活発に見えなくなっちゃってプロダクトの死に近づいちゃうみたいなの、どうしてもあるので。
それはそれとして、今度レイヤードアーキテクチャだとかDDD的な設計とか話したいということもワイワイ話せたので良かった。
今度、梅田で夕飯などを食べながら技術を語る会のようなものをできたらいいなぁと思ってます。