技術におけるフレームワーク
意思決定のフレームワーク。
- 技術選定において、その技術は適度に枯れているか？
- 技術は手段でもあり目的でもある
- 技術はあくまで問題を解決するアプローチに過ぎない。ただ一方で、技術を楽しむ気持ちを尊重し、育む必要がある。
API First / The API Mandate を採用する
- すべてのチームは、今後サービスインターフェースを通じてデータや機能を公開する
- 各チームはこのインタフェースを通じて相互に通信しなければいけない
- すべてのサービスインタフェースは例外なく、外部か可能なように1から設計しなければいけない。チームは外部の開発者にインタフェースを公開できるように計画・設計しなければいけない。例外はない
この概念を支持しています。 マイクロサービスを検討有無にかかわらず、最初からインタフェース非公開前提でDBから直接アクセスした設計では、インフラ層が密結合になってしまい、改修コストが跳ね上がった経験があります。 また、インタフェースが公開できる状態というのはリポジトリ・プロダクトのドキュメンテーションという点においても正しくワークしている状態であり、インタフェースが公開できない状態は荒れているシーンが多々あります。
参考
- The API Mandate - Install API Thinking at your Company – API-University
- API Mandate: How Jeff Bezos’ memo changed software forever
OOP way 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の最小２つで管理することができうると考えています。
- https://legacy.reactjs.org/docs/shallow-compare.html
- props がオブジェクト・配列・関数の場合にコンポーネントが再レンダーされる
- DDD and react : r/reactjs
KISS（Keep it Simple, Stupid）
Keep it simple stupid.（シンプルで愚鈍にする）1
過度な設計や過度な機能。例えば、ブログを書こうとしてブログサイトにこだわりすぎてしまう現象。 度々やってしまうが、システムにおいてもシンプルに、愚鈍にしておくことを選択肢にもち、よしとする。
過度に時間がかかっているときはKISSを思い出し、解決策とする。
- Twelve-Factor App
- Beyond the 12 factors