技術日記6/10-6/14

ドメインオブジェクトの設計にテーブル設計もある程度引っ張られるのかと思ってたけどDDDにおけるドメインオブジェクトの設計とテーブル設計は全く別物として考えていいっぽい
これなら割とお試し？的にDDDやっていけるかも
ドメインオブジェクトはガンガン変更加えていくやつっぽいし

デザインができてきたのでここでgraphqlの設計を一部修正加えた

boostnoteでいろんなノートを取るようにしたら作業ログを取りにくくなってきた
作業ログ用専用ツールがほしい

javaの日付系ライブラリ何使えばいいのかずっと整理できてなかったけどやっぱりjava8以降では標準のTime Api使えば良いっぽい
ただ機能過多感が...
しかもまだまだjava8が広まりきってないのか知らんけど、protocol buffersのTimestampではjoda time使ってるし...

graphql×grpc通信のマイクロサービス×RDBという構成で作ってるけど、graphqlのオブジェクト設計とprotocol buffersの設計とtable設計で三箇所ほどでオブジェクトの設計をすることになっている
graphqlとtable設計でデータの持ち方（粒度）が違うのだけど（graphqlオブジェクトを取得するのにtable2,3個見る必要があるとか）
このときprotocol buffersはどんなふうに設計するかと言うのをちょろっと考えたけど、今回はgraphqlとprotocol buffersの設計粒度は基本揃えることにした
理由としてはまずgraphql api（ゲートウェイサーバー）の仕事をシンプルにしたかったから
graphqlとprotocol buffersの粒度が揃っていない場合、別のgrpc呼び出しで取得したものをgraphqlサーバーで加工する必要が出てくると思う
ただなるべくそういったロジックのようなものはgraphqlサーバーではやりたくないなと思った
protocol buffersの設計粒度を細かくすれば、graphql意外の呼び出しとかにも対応できそうだけど、そのシチュエーションはあまり思いつかなかった
graphqlの設計変更につられて修正を入れるということはありそうだけど、そこはまあgraphqlの設計がミスってるせいだから
それにオブジェクトの設計がそれぞれのレイヤーでバラバラになりすぎると管理がめんどくさくなりそうだったから、揃えられそうなところはなるべく揃えたいというのもあった
ただテーブル設計は上のレイヤーの設計には引っ張られずにちゃんと正規化するべき

今更だけど初めてbinary search使った
この前アルゴリズムの勉強したからな
binary searchなんて基礎中の基礎だけど大事だわ
やっといてよかった
もっとアルゴリズムのちから伸ばしたいしAtcoderとかもやっていきたい

作業ログ残すときエラーメッセージと対応したときのコードも残せる場合は記録するようにした
ブログに落とし込むときとかそのまま貼れそうだし

graphql javaはslf4j使ってるのでlogback入れた
ログないとデバッグきつかったのでもっと早くやっといても良かった

テストコード書くのにkotlintestを使っていたけど、DIにKoin使っていて、両方共クラスの継承使ってて、なんか書き方が競合してるような感じで上手く一緒に使えなかったのでkotlintestは使うのやめた
Koinのテストとmockkは一緒に使えた
mockkはかなり使いやすいから安心した
kotlinはデフォルトでassert()関数持ってたけどログが微妙だったのでassertk入れた

殴り書き終了！ Koinとmockkの部分は別記事にまとめたいな