フロントエンドのモデル駆動設計の座談会に参加しつつ気になったことを可能な範囲でメモします。
https://modeling-how-to-learn.connpass.com/event/308018/

前段

• この会は成功例よりむしろうまくいかなかったなど現場の泥臭いもの扱いたいとのこと。
• フロントエンドに関わらず複雑さを扱うためにモデル・モデリングを活用する。
• 企画の始まりはBEの佐藤さんがFEもやる様になってよくわからないという相談から始まり、僕に相談が来た。色々みなさんに声かけて始まった。

自己紹介中にでた話題

• Feature-Sliced Design
• DMMF（Domain Modeling Made Functional）

佐藤さんの悩み

• BEのアーキテクチャがそのまま使えるのかどうかわからない
• BEから見たUI層という単純な話にはならない
• UIとビジネスロジックは切り離したいが
• ステートレスにしたいがコンポーネントに集約していくとステートフルになってしまう
• テストどこまでやるべきか？結合テストやHooksのテストはどうするのか？

オブジェクト指向

• BFFかBEかFEかロジックをどこに置くかによってアーキテクチャも変わるのでFE/BEで知識的な共有ができるかは
• BE/FEでsharedにロジック層を置くので依存度が高まりそう
• さくらインターネットではBEが古くからあるのでAPIよりBE側と完全に切り離してFEでモデルレイヤーを持っている
  • APIが必ずしも正しいEntityとは限らないこともある
• Web, Nativeなどclientが様々ある場合にはBFFを用意して BE ↔︎ [ [ BFF ↔︎ FE ], [ BFF ↔︎ FE ], ... ] という感じにする

ステートレス・フル

• コンポーネントをステートレスに必ずしなければならないのか？
  • そんなことはない
  • Compound Pattern でルートからContextで子コンポーネントとや Container Pattern でPropsで流し込むなどすれば良い
  • そもそも画面は何かしらの状態を持つものなのでユーザから見ればステートフル。実装者から見ればデータの捉え方で部分的にステートフルであったりステートレスとなったりする