ORMに感じるもやっと感
SpringBootでWebアプリを作るとき、いつもDBアクセスに何を使うか悩む。Doma?Mybatis?JPA?
個人的にはどれもしっくり来ていなくて、なんだかんだでDomaを使っている。何にもやっとを感じているのか考えてみた。
ドメインモデルへのマッピング
ほとんどのWebアプリのドメインモデルは1:*のようなマッピングが存在していて、SQLの結果を親子関係を持った構造にマッピングしたい。
SQLはjoinなどで持ってくるとflatな構造なので頑張ってドメインモデルに詰め替える必要がある。これがとても面倒くさい。
Mybatisを使う場合、resultMapで関連のマッピングを定義する方法が用意されている。とはいえSQLをXMLに書きたくないので、SQLの置き場としてはやっぱりDomaが好きだなーというお気持ち。
JPAはORMの都合をあまりドメイン層に持ち込みたくないのでなんだかなーということであまり使ってない。あと複雑なクエリは多かれ少なかれなんだかんだ書くことになるので、SQLを自分で書くタイプのほうがいいよなーって感じがする。
仮説：リレーションのマッピングができれば嬉しい？
基本的にDomaで事足りていて、あとはリレーションのマッピングをいい感じにしたいだけなのでは？ということはマッピングをするところだけライブラリにしてしまえば良さそう！
ということでKtMapperというライブラリを書いてみた。
レコードのオブジェクトをドメインモデルに変換するMapperをKotlinでDSLっぽく書けたら便利かもねという思想。
サンプルで書くとこんな感じ。
10連休終わるまでにもうちょっと素振りして検証してみよ〜
最近コードを書くときに考えていること
最近Rubyを書くことから少し離れてKotlinをメインに書くようになったので、最近どんな事を考えてコードを書いているか書いてみる。
ValueObjectに注目する
とにかくクラスをサボらず作る。そうすると大体はValueObjectになる。ロジックの置き場はとにかくValueObjectにおいていく（というか自然な場所を探すと大体そうなる気がする）
Listみたいなコレクションもクラスにラップする。区分の組み合わせから値を導き出すとかよくあるロジックだけど、抽象度がだいぶ低いので隠して名前をつけたい。
具体的な例で言うとOpenID Connectのresponse_typeとか。
response_typeの例
openid-foundation-japan.github.io
OpenID Connectの仕様によると、response_type(3種類の列挙値)は組み合わせ可能で、組み合わせによって選択されるフローがかわる。しかも存在しない組み合わせもある（！）
ResponseTypesにListGrantType grantType() みたいなメソッド生やすのが良いのかなーとか思ったり。
永続化層をできるだけ意識させない
RDBに保存するとかHibernateやMybatis使うとかそのへんをあまり意識させないようにする。infrastructure層から外にライブラリの都合を出したくないなー。ORMを置き換えたりデータストアを置き換えるのはそうそうないと思うけど、なんだか気持ち悪いや。
生やすメソッドはRDBのRepositoryならjava.util.Listっぽいかんじ。RedisみたいなKVSならMapっぽい感じのメソッドがあるとよさそう〜。あとfindByXXX系のfinder系のメソッド。
Transactionはapplication層でかけちゃうけどこれいいのかな・・・これってインフラ都合じゃね・・・？とか思わなかったり。
クラスの依存関係に気を配る
ArchUnitを入れてレイヤー間の依存関係、サブパッケージ間の循環依存に気を配れるようにする。テストが落ちたらなにかモデリングがまずそうなので考え直す。
値の範囲に気をつける
ValueObjectの取りうる範囲が分かっていると考えることが一気に減るので考えるのが楽になる。区分なら列挙だし、期間なら小さい日付から大きい日付の間、個数なら0以上、X以下になりそう。
システムのリプレースならGROUP BYやMIN/MAXをDBに打って値の取りうる範囲を見つける。まぁ大体変な値が入っていてDBのお掃除をするところから始まったりする。
GROUP BYを打ったら謎の区分が出てきて膝から崩れ落ちる回とかも発生しがちなので心を強く持つ。
BIG QUERYにデータが乗っているとかあれば、NOT LIKE '%XXX%' みたいな感じでバリデーションかけられるか調べてみても良さそう。BIG QUERYなら謎の技術でめっちゃ早い。indexとか存在しない世界なのでとりあえず殴っていける。
おわり
たぶんこんな事考えながらコードを書いたりしてる。ところでDDDの境界付けられたコンテキストの概念難しいんだけど、おれきゅーさんにおしえてくれませんか？😭
技術的な判断をするときの考え方を文字にしてみる
会社に新卒が入ってきて、判断をするときにこういうこと考えるといいよねーってことを伝えられるように、いつも考えてることを文字に起こしてみる。
作る必要ある？
何かしらを作ると作っただけ複雑になる。なにもないのが一番単純。作らないのが一番楽だよね〜。
だから作らずに目的達成できるならそっちのほうがいいし、もしかしたらそもそもいらないかも。何もしなくて良いなら絶対そっちがいい！
働かなくて良い道を選びたい。
これは取り返しがつく選択？
なにか技術的な選択を迫られたとき、取り返しがつくかどうかを考える。
あとからもう片方の選択肢に切り替えられるなら、まぁどちらでもいいかなー。メリット・デメリットの天秤にはかけるけど、取り返しつくし。
AとBの選択肢があって、A→Bの切り替えはできるけどB→Aにするのは難しいといった場合は、Aを選ぶことが多いかも。もちろん天秤にかけたあとで。判断がどうしてもできない場合は取り返しが付きやすい方を選んでおいたほうが失敗したときにリカバリーしやすい。
どちらに転んでもリスクが小さい場合（たとえばlintを入れるか入れないかとか）は「どっちでもいいし、強いモチベーションがない」とかを明言しつつ試しにやってみて微妙ならやめよう！みたいな感じで良さそう。
運用するとき困らない？
人間が頑張って運用でカバー！は最後の選択肢。人間はミスるし、そういう面倒な作業は精神的にしんどい。楽しくない。
あと積み重なると気づいたときにはタスクに押しつぶされてたりする。運用も一緒に考える。
あとから変更するときこまらない？
区分を増やすとか処理をふやすとか、ある程度想定のつくものを増やそうとしたときどこを編集すればいいか考えておく。
「こことこことここを変えないといけない！（すごい散らばった場所に対して」とか変更漏れ発生しそうだなーと思ったら考え直す。
普通を好む
フレームワークの普通とかRFCに書いてある普通とかそういったものを好む。こういったものを作っている人は大体は自分たちより経験値を持っていてすごいエンジニア。できる限りこれにそって作ったほうが良い。オレオレの何かをやると大体のケースでバグったりセキュリティホール作ったりする。
フレームワーク文脈でいえばリフレクションとかで「privateなメソッド呼んでやったぜ！」とかドヤ顔してしまうとほぼ確実に痛い目を見る。普通に使わない人は互換性のサポート対象外だ。
