FlutterとSSOT原則
はじめに
自分自身はWebエンジニア出身でFlutterでの開発経験はほぼ皆無なのですが、個人的に最近Flutterの勉強を始めています。
最近Flutterのアーキテクチャを勉強していてSSOT原則という言葉をよく聞くのでまとめてみました。
SSOTとは？
Single Source of Truthの略で日本語でいうと、信頼できる唯一の情報源という意味。
SSOTを考慮しない状態って？
分散した各業務でそれぞれ作成・編集されているデータが存在するような状態。
データ活用のためにこれらを統括して利用したい場合、分散していると以下の問題が発生します。
- 正確性の担保が難しい
- 同様のデータが複数の業務で保持されており、どのデータが最新で正確な情報かわからない
- この問題はマスタデータ等の複数の業務で共通で必要となるデータで該当しやすい
- 一貫性の担保が難しい
- 1つ目の正確性の問題に関連してどのデータを使うかによって結果が変わるので、常に同じ結果を出す一貫性の担保ができなくなります
- 情報の探索性の担保が難しい
- あらゆる所にデータが分散しているので、どこに求めるデータがあるのかを探す所から始める必要があり、スピードを遅らせる大きな原因となります。
SSOTを考慮した状態管理を意識する
前述は一般的なSSOTについて触れましたが、これをアプリケーション開発に当てはめると状態管理について考える際にSSOTの原則は役に立ちます。
SSOTを実現するには、保持しているデータを正規化し、データの重複をなくしていく必要があります。
Flutterの状態には以前の記事で触れた通り、Ephemeral StateとApp Stateがありますが、複数の開発者で実装している場合、App Stateは自分が作っているコンポーネント以外の開発に大きく影響を与えるので、信頼できる唯一の情報源になっているか、その粒度と保持する内容について他のメンバーと議論して認識を合わせることは非常に重要になると思います。
SSOTと単方向データフロー
前回書いた記事の参考資料でも触れられていましたが、SSOTを実現しようとすると信頼できる唯一の情報源となるソースを用意する必要があります。
社内システムでいうとBigQueryのような全社データ基盤がそれにあたり、クライアントサイドのアプリケーションでいうと、単方向データフローにおけるStoreがそれにあたる感じです。
SSOTを実現するアーキテクチャを考えていると、MVVMって難しくないかと感じました。
状態がUIに密接に紐づいているので、それぞれで状態を持っていて絶対に信頼できるソースがあるとはいえない状態になるんじゃないかなーと。
そんな背景もあり、単方向データフローとSSOTはセットで話されることが多いのかなと思いました。
所感
SSOTと単方向データフローは密接に関わっているので、monoさんのこの記事でも第一に押さえておくことだと言われてたんだな〜ということが何となくわかりました。
またSSOTの粒度が適切になっているのかを定期的に見直すためにテストコードを書いておくことも重要そうです。他のエンジニアが見た時にすぐにわかるような状態管理を心がけたいですね。
今回以下の資料が参考になったので載せておきます。
Discussion