to fasten one thing to another using a screw or screws 冗長だよなー１つと2つ以上みたいな
「a screw or screws」じゃなくてscrewsだけでいいって思う
会話はいいけど
✅ 普通の文・会話 複数形でOK using screws, eating eggs 📘 辞書・マニュアル的説明 a ~ or ~s using a screw or screws
数字が定義していない。 1つじゃないとだめだったのに1つしか使ってないとかで訴訟リスクを防ぐためみたい
🔹 “non-stick” が特殊な理由
普通なら「くっつかない」という意味なら “non-sticky” にするはずですが、 “non-stick” は「くっつかないように作られた」という機能性（functional）を表したいので、 あえて動詞 “stick” の原形を使っています。
つまり：
non-stick → “stickしないようにする” → 機能・加工（functional）
non-sticky → “stickyじゃない” → 感触・状態（tactile）
🔹 同じパターンの例 単語 意味 コメント non-slip shoes 滑らない靴 “slip” = 動詞（滑る） non-drip bottle 液だれしないボトル “drip” = 動詞（したたる） non-stick pan くっつかないフライパン “stick” = 動詞（くっつく）
これらはすべて「動詞の原形」を使って「〜しないようにする機能」を表しているんです。
🔸 まとめ 形 品詞 意味 例 non + 動詞原形 機能・用途 「〜しないように作られた」 non-stick, non-slip non + 形容詞 状態・性質 「〜でない」 non-sticky, non-alcoholic non + 名詞 種類・区別 「〜ではない人・物」 non-smoker, non-fiction
UI Layer Case Study（要約）
結論：各機能のUI層は View と ViewModel のペアで構成。
ViewModel：UIロジックと状態管理を担当（入力＝Repository群／出力＝UI State）。
View：ViewModelが持つ状態を描画し、ユーザー操作をViewModelのコマンドに渡す。 → 1機能 = 1 View + 1 ViewModel（1対1の関係）
ViewModel ― 役割と設計
依存関係：必ず1つ以上の Repository に依存（多対多）。コンストラクタで受け取り、private フィールドに保持（Viewからデータ層を隠す）。
UI Stateの公開：User? user、UnmodifiableListView
データクラスは freezed で深いイミュータブル化（copyWith/toJson 自動生成）。
更新通知：ChangeNotifier を継承し、状態更新後に notifyListeners() を呼ぶ。
イベント処理：削除などのユーザー操作は コマンド（Command） として公開。中ではRepositoryを呼び出して永続状態を変更し、最後に notifyListeners()。
View ― 役割と設計
入力：基本は key と 対応する ViewModel のみ。
責務：
ViewModelのデータを表示
ViewModelの変更を購読して再描画（ListenableBuilder(listenable: viewModel) など）
イベントを委譲（ボタン押下で viewModel.deleteBooking.execute(id) など）
実装例：HomeScreen は ListenableBuilder でViewModel/Commandの状態（実行中・成功・エラー）に応じて
ローディング表示
エラー表示＋再試行ボタン
本来のUI を切り替える。
Command パターン（本事例の肝）
目的：UI→データ層への処理の往復で、実行中・成功・失敗 を安全に扱うためのヘルパー。
仕組み：Command
使いどころ：
画面初期ロード：load = Command0(_load)..execute()
項目削除：deleteBooking = Command1(_deleteBooking)
利点：データ到着前でもビューが安全にレンダリング可能（コマンドの状態に合わせたUI分岐）。
代替：自作せず flutter_command の利用も推奨。Stream/StreamBuilder を使う場合は AsyncSnapshot が近い役割。
実装ポイント（抜粋）
不変データ＋最小ロジックのView＋状態はViewModel。
Repositoryのみがアプリの永続状態を変更（SSOT）。
ViewModelは 複数Repositoryを統合・整形 してUIに最適化。
ChangeNotifier/ListenableBuilder は標準機能で十分だが、Riverpod / flutter_bloc / signals などの採用も可。
まとめ
UI層は 「UIは状態の関数」 を徹底： ViewModelが状態を管理 → Viewは状態を描画 → イベントはCommand経由でデータ層へ。
Commandパターン により、非同期・エラー・再試行・ローディングの扱いが統一され、堅牢でテストしやすいUIになる。
https://docs.flutter.dev/app-architecture/case-study
🧭 概要
このガイドでは、Compass アプリという実例を通して、Flutter の推奨アーキテクチャ（MVVM パターン＋Repository/Service 構成）をどのように実装するかを解説しています。Compass は旅行の行程を作成・予約できる本格的なサンプルアプリで、実運用を想定した大規模構成になっています。
🧩 学べる内容
Flutter のアーキテクチャガイドを実装する方法
Repository と Service を使ったデータ層設計
MVVM による UI 層設計
Command パターン を用いた安全な UI 更新
ChangeNotifier / Listenable による状態管理
Provider パッケージを用いた依存性注入
推奨アーキテクチャに沿ったテスト構成
大規模 Flutter アプリのための効果的なパッケージ構造
🏗️ パッケージ構成のポイント
📁 ディレクトリ構成（例）
lib/
├── ui/
│ ├── core/ # 共通UIウィジェットやテーマ
│ └──
テスト関連：
test/ # ユニット & ウィジェットテスト testing/ # モックやフェイクなどのテスト補助コード
💡 設計の考え方
UI層（View / ViewModel） は機能単位（feature-based）で整理。 → 各機能に1つの View と 1つの ViewModel を持つ。
データ層（Repository / Service） は型単位（type-based）で整理。 → 複数機能から再利用できるよう設計。
domain層 にはアプリ全体で共通するモデルを配置。
coreフォルダ はブランドテーマや共通UI（ボタン・フォーム等）を格納。
3種類の mainファイル（開発・ステージング・本番）を使い分け。
🔁 他のアーキテクチャとの関係
この事例は MVVM + ChangeNotifier を採用していますが、 同様の構成は Riverpod, flutter_bloc, Signals などでも実現可能です。 また、データ取得をメソッド呼び出しではなく Stream で実装することも可能です。
🧠 まとめ
Flutter チーム推奨の「MVVM + Repository + Service」構成を実例で解説。
コードの見通しが良く、スケーラブルでテスト容易性が高い。
FeatureごとにUI層を分割, Typeごとにデータ層を分離 が基本方針。
