Flutterでスケールするアプリ設計 Store編 - タオルケット体操
hachibeechan.hateblo.jp 前回の続き そういえば、前回の記事のブコメで Behavior = TransactionScript? 実践CQRS という感じの元ネタばらし鋭い指摘をしてくれた方がいました。 90%方その通りなのですが、実装の平易さ、許容できるパターンの広さを優先するために元の定義からかなり離れてしまっており、混乱を招くかもしれないと感じたので別の用語で説明している次第です。 読み返すと文字の密度が高くて読むの大変な記事ですね。 今回は具体的な話になるのでサンプルコードとか載せられるといいなとおもいます。 スケーラブルなデータ設計の基本アイディア Storeの構成要素 アンチパターン 1. Modelという名前がついたクラス 2. "DBに対するCRUD操作" のような抽象度でStoreを設計してしまう 3. 同一の対象を表すデータが複数存在している（N
Flutterでそこそこ規模の大きいプロダクションアプリを作ったのでスケールする設計についてまとめる - タオルケット体操
あわせて読みたい FlutterでBLoCだChangeNotifierと振り回されて消耗するまえに - タオルケット体操 筆者のFlutterに対する印象は半年前にこのエントリーを書いたときから驚くほどに何も変わっていないので、逆にFlutterは非常に明快でわかりやすいライブラリなのかもしれないですね。 hachibeechan.hateblo.jp 筆者の主張の事前まとめ Reactの学習は実質Flutterの予習 クライアントアプリを設計するにあたってはActiveRecordパターンの再発明をしてはいけない 結局MVX RXSteamとはなんだったのか DDDの勉強をすると多くの示唆を得られる Remi wareを信じろ ちなみにここ以下で述べるActiveRecordパターンはPoEEAとRoRのものの混合があるかもしれませんが、利用すべきじゃないという点において同一なので特に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
