📐 006 4+1 Viewアーキテクチャ
4+1 View Model・システム全体俯瞰図
設計書 v1.0 / 2026-04-21
1 4+1 View Model について
ソフトウェアアーキテクチャは、単一の図面や視点だけで全体を表現することは困難です。 **「4+1 View Model」**は、1995年にPhilippe Kruchtenが提唱した設計フレームワークであり、システムを「論理」「プロセス」「開発」「物理」の4つのビューと、それらを統合する「シナリオ」という5つの異なる視点から表現することで、すべての関係者（ユーザー、開発者、SysAdmin）に明確な理解を提供します。
2 論理ビュー
対象: エンドユーザー、システムアナリスト。システムが提供する機能要素とドメインモデルを定義します。
2.1 コアドメインモデル：付箋（Fusen）
本システムの最も重要な論理エンティティは「付箋（Fusen）」です。PCではMarkdownファイルとして、iPhoneではIndexedDBオブジェクトとして存在しますが、論理的には同一のエンティティとして扱われます。
図 6-1 論理ドメインモデル関係図
2.2 フロントエンドの状態分離
- ViewingMode（閲覧モード）: HTML/CSSで高速レンダリングされた状態。
- EditingMode（編集モード）: CodeMirrorインスタンスが立ち上がった状態。
3 プロセスビュー
対象: パフォーマンステスター、アーキテクト。並行処理、同期、IPC（プロセス間通信）、バックグラウンド非同期処理の実行モデルを定義します。
3.1 非同期メッセージングとイベント駆動処理
本システムは「ポーリング」と「イベント駆動（Push）」を適材適所で組み合わせて並行処理を実現します。 PC（Tauri）はバックグラウンドスレッドでイベントを監視（tauri::async_runtime）し、iPhone（PWA）は Service Worker を通じてブラウザのメインスレッドとは独立したプロセスでデータを受け取ります。
図 6-2 通信およびバックグラウンドプロセスのタイムライン
4 開発ビュー
対象: 開発者、プログラマー。ソフトウェアモジュールの階層構造、ディレクトリ構成、ライブラリスタックを定義します。
4.1 モノレポアーキテクチャ
本プロジェクトは単一のリポジトリ（モノレポ）で「PC（Tauri）」「iPhone（PWA）」「Vercel（API）」のすべてのコードを管理しています。フロントエンドを Next.js（React） で統一することで、UIコンポーネントや型定義（TypeScript）を共通化しています。
表 4.1-1 モノレポアーキテクチャ概要
| ディレクトリ | 責任範囲 | 技術スタック |
|---|---|---|
src-tauri/ | PCアプリのコアロジック、OSネイティブAPI（ウィンドウ操作、トレイ）、ローカルファイルI/O | Rust (tokio, tauri, reqwest) |
app/viewer/ | iPhone PWA および Vercel API Routes のエントリーポイント | Next.js (App Router), React, Google APIs |
app/page.tsx 等 | PCアプリ用のフロントエンド・UIコンポーネント群 | Next.js, Tailwind CSS, CodeMirror |
| ディレクトリ | 責任範囲 | 技術スタック |
|---|---|---|
public/worker/ | iPhone バックグラウンド同期と通知処理 | Vanilla JS (Service Worker API), IndexedDB |
.github/workflows/ | CI/CD パイプライン（自動ビルド、Winget自動リリース） | GitHub Actions |
5 物理ビュー
対象: インフラエンジニア。システムがデプロイされるハードウェア、ネットワーク、実行コンテキストを定義します。
5.1 ランタイム環境とネットワーク・トポロジー
本システムは中央集権的なデータベースを持たず、**「ユーザーのデバイス（Edge）」と「ユーザー所有のパーソナルクラウド（Drive）」**のみで完結するピュアな分散コンピューティングモデルです。 Vercelは静的ファイルのホスティングおよび一時的な認証プロキシ（OAuth2 Secret の秘匿）のためだけに存在します。
図 6-3 物理デプロイトポロジー
6 ユースケース（Scenarios）
対象: 全ステークホルダー。4つのビューを実証する代表的なユースケースのシナリオです。
6.1 中心シナリオ: 「出先での確認と返信」
本アーキテクチャの存在意義と4つのビューの連携をもっとも色濃く反映している一連のシナリオ（ユースケース）です。
表 6.1-1 中心シナリオ展開
| ステップ | ユーザー視点のシナリオ展開 | アーキテクチャの関与ビュー |
|---|---|---|
| 1. PCで入力 | ユーザーがPC上で「買い物リスト」を書き、「iPhoneに送る」ボタンを押す。 | [Logical] Fusen オブジェクトの生成 [Development] RustモジュールによるファイルI/O |
| 2. クラウド中継 | 数秒以内にノートがクラウドにアップロードされ、通知発火のトリガーが引かれる。 | [Physical] Local PC → Google Drive 通信 [Process] APNs への非同期 Push API 呼び出し |
| 3. iPhoneで受信 | ユーザーが外出先でiPhoneを見ると、ポケットの中で既に通知（新着ノート）が届いている。 | [Process] Service Workerのバックグラウンド起床とDrive取得 [Physical] Safariサンドボックス内でのIndexedDB保管 |
| 4. 返信して削除 | iPhoneから「牛乳買ったよ」と追記してPCに送り返し、手元のノートを消す。 | [Logical] Viewing/Editing Mode の遷移（PWA） [Process] PCの30秒ポーリングによる即時回収と自動削除 |
7 改版履歴
表 7-1 改版履歴
| No | バージョン | 日付 | 変更内容 |
|---|---|---|---|
| 1 | 1.0 | 26-04-21 | 新規作成。4+1 View Model（論理・プロセス・開発・物理・シナリオ）全ビューを整理。 |
| 2 | 1.1 | 26-04-24 | classDiagram・物理ビュー flowchart を LR（横向き）に変更。スクロールなしで全体が見えるよう改善。 |