Yoshi.dev

技術系の趣味、またはやった仕事やそこから学んだことを忘れないために

技術日記というか週報5/13-17

今週(先週)はリファクタリングいっぱいしてた

クリーンアーキテクチャやる上でDBトランザクションどうするかという問題についていくつか考えてた

https://blog.cleancoder.com/uncle-bob/images/2012-08-13-the-clean-architecture/CleanArchitecture.jpg

(とりあえず有名なやつ貼っとく)

  1. インターフェース層でトランザクションを管理できるようにして、コントローラーからユースケースを呼ぶタイミングでトランザクションを貼る。
  2. リポジトリレベルでトランザクションを貼る
  3. なんとかしてユースケースからトランザクションを使えるようにする
  4. ユースケースリポジトリの間にゲートウェイ的なものを用意してそこでトランザクションを貼る

それぞれについてより細かく書くと
1は割と簡単にできる方法。(もともと自分間違えてたけど)DBクエリを書いたりするのはインターフェース層で、コントローラーと同じ層になるので、コントローラーの中でもいわゆるORマッパー等の機能を使うことができる。なのでコントローラーからユースケースを呼ぶ際にトランザクションを貼ることができる。ただ若干気持ち悪い気もする。しかし、トランザクションという概念がRDBのものなのでそれとユースケースをつなぐという意味でもインターフェース層にあってもまあいいかなーとも思った。ちなみにもともと自分はFramework&Driversの層にクエリも書くもんだと思っていて、なかなかこのやり方に気が付かなかった。

2はユースケースから呼ばれるリポジトリ(インターフェース層)にトランザクションを貼るやり方。個人的にユースケースレベルでトランザクションを貼りたかったのでこのやり方も微妙だと思ってた。ただDDDの集約の考え方を取り入れるとうまくいきそうとも思った。集約とは整合性を保ちながらデータを更新するオブジェクトのまとまりという感じらしく、リポジトリを集約単位で切ればリポジトリレベルでのトランザクションはありだと思った。ただ集約を見極めるのが難しそうだとも思った。もともとDDDの中で出てきた考えだからしっかりとDDDを実践した中で取り入れる考えなんじゃなかろうかと思って今回は見送った。

3はまあやりようはあるのかなーとも思ったけどめんどくさそうだからやめた

4はリポジトリと同じインターフェース層(トランザクションの制御ができる層)にゲートウェイを設けるやり方。ユースケースから直接リポジトリは呼ばずに、ゲートウェイの中で同一トランザクションで処理したいものを書いていく。これも簡単にできるしリポジトリトランザクションの責務を持たせずに済むけど、トランザクションのパターンが増えるごとにゲートウェイのパターンも増えていく。ちなみにググってて思ったけどこれはCQRSのコマンドってものに近いんだろうか?

結論現状は一旦1のパターンですすめている(簡単だし十分役割を果たせてると思うから)

GraphQL Java使ってたけどGraphQL Java Toolを使ってなかった。 DataFetcherのマッピング(resolverって名前になってたけど)を自動でやってくれたりして記述量が減って楽になった。

スクレイピングjavascriptを使ってたけどtypescriptに書き直した。 今どきのjavascript新規プロジェクトは最初からtypescriptでやるもんらしい? とりあえずやはり型がある方がしっくり来る。 もともとtypescriptを入れることは考えていたけど、jsでどこまで行けるかなーって感じでjsのみで書きすすめていた。 RDBと接続するところで。あ、これ型ないと無理だわ...って気づいた(気づくの遅い) typeormというORマッパーもあっていい感じだ

以上