クリーンアーキテクチャ・DDDでN+1問題を起きた時の対処方法は？
とある商談で
「クリーンアーキテクチャの設計してて。よくN+1問題がおきるんだよね〜。どう回避しますか？」
という商談での話での感想
状況としては商談の相手先の開発設計がクリーンアーキテクチャになっていました。
自分個人としてはクリーンアーキテクチャは間違っていると思うのですが、商談では
「自分がいちからクリーンアーキテクチャで設計した経験はないです。
しかし、違う現場で違う設計思想に触れたいとは思います。それがフリーランスになった理由でもあります。」
と回答しました。
フリーランスなので設計思想とかクライアント次第な所があるので意地を張る必要もなく、「勉強したいです」という風な姿勢が必要なのではと思いました。
フリーランスなのでクライアント様、お客様のいう通りが全て
生産性や安定性、エンジニア確保などなど気にする必要はなし
とあきらめてしまえば案外気持ち的にスッキリした気がしました。
商談が進むにつれて開発設計の話に進んでいきました。
N+1問題がこの現場ではよく起きる問題で
それに対してどう対処しますか？
という問いが来た
しかし、N+1問題自体知らないのでそのまま
「わからないです。どういったものでしょうか？」
と質問
「説明が難しいですがDBの負荷的な問題」
と回答だったので、メモリに逃したり、別DBに逃したり、キャッシュしたり
などごくありふれた回答しかできなかったです。
後々 N+1 問題を調べたらループの中でselect文をしているのが典型例だそうです。
そんなポンミスなんてなんで起きるのかを考えてみた
あ！クリーンアーキテクチャが原因！
クリーンアーキテクチャでいう各レイヤー(クラスの事!?)に分けて〜という思想で各開発者が開発してたとしたら。。
「そのレイヤーがまさかループしてるなんて聞かされてなかった！？」
とかのケースであればあり得るのではと思いました。
ループの中でselect文はあまりにも簡単な例で普通はそんな事はなくても同じテーブルを別々のレイヤーのselect文で参照するって事はありえそうです。
商談中にこのN+1問題がなんのかわからないので何も言わなかったけどももしこの事を知っていたら
「クリーンアーキテクチャやめたらいいやん！」
って言ってたかもしれないです。
でも、今はしがないフリーランスなのでそういう事は言わずしたの記事につぶやきにもあるように
MVC
— medy.nim🐍👑@DecentralizedWeb (@dumblepytech1) August 23, 2021
↓入力フォームとテーブルが一致しなくなる
MVC+S
↓JOINした後のテーブルをドメインモデルとして使いたくなる
M(VO,E,S,R)MC=DDD
↓エンティティを参照系で呼ぶとN+1になる
DDD+CQRS
↓画面仕様に合わせてデータ整形が必要になる
DDD+CQRS+DTO
「CQRSでN+1問題を回避します。」
と回答すればこの思想の人にはバッチリ当てはまる回答かと思いました。
WEBのサーバーサイドなんて
DBとかのストレージの情報を引っ張ってきたり
登録・更新・削除するだけ
の事でとてもシンプルで簡単なのですが、これらの無意味な設計思想ががために簡単な事をより複雑化しています。
その複雑さゆえフリーランスの単価が上がるので皮肉なもんです。
このクリーンアーキテクチャは設計しているエンドユーザーにとって得はないです。
でも、フリーランスにとっては単価が上がるので、お得なソリューションと言えるかもですw
なので、皮肉を込めて
クリーンアーキテクチャ・DDD万歳！！
登録日：
更新日：