Don't using OOP way on Frontend DDD

OOP（オブジェクト志向）とReactは相性が悪く、OOPでのDDDはReactに導入する場合は発生するコストやリスクを踏まえて導入を決めます。

ReactはRe-renderingの仕組みがオブジェクトの場合、参照等価です。

※参照先を確認中です。Shallow Equalとして認識しています。Deep Equalをしている場合、同一インスタンスでも変更があったプロパティをチェックした上で差分を検知できますが、パフォーマンス上ReactはShallow Equalを採用しています。

フロントにおけるユーザーは大抵一人であり、StoreでUserStoreを管理すると、OOP wayではシングルトンでの実装となります。そうなると、深いネストを持った同一インスタンスがStoreに保存される形となり、Renderingの条件と噛み合いにくくなります。

その解決策としては Immer を使って immutable として取り扱うことです。Zustandでは Immer middleware が提供されており、相性がよいです。

個人的には言語仕様として相性が悪いものは採用しないほうがシンプルであると考えていますが、その前提でOOP/DDDを採用するなら良いと思います。

逆に、関数型としてのDDDや Immutable な取り回しを前提としたものも良いと考えています。が、DDDにおけるビジネスロジックはバックエンドに集約させる方が良いと考えており、Frontend（React）もプレゼンテーション層の一部のViewであると捉えるのが今の支持です。

昨今はAPI RequestのCache戦略として TanStack Query や SWR などでGraphQLのように、バックエンドのデータストアをクライアントのStoreとして扱えるようなキャッシュ機構が増えています。

極力ViewとしてのReactアプリケーションと割り切ると、クライアントアプリケーション内でRoot的なStore管理をする必要が減り、Request CacheとLocal Stateの最小２つで管理することができうると考えています。