会員証アプリの設計
設計では、要件定義で整理した「なにがしたいか」を「どう実現するか」に落とし込みます。
ここでは、システム構成と分割の意図、そして設計判断の残し方を紹介します。
システム構成
graph TB
subgraph Product["会員証アプリ本体(開発範囲)"]
App["会員アプリ<br/>(エンドユーザー向け)"]
Admin["管理画面<br/>(運営・テナント・<br/>ショップスタッフ向け)"]
Backend["業務 API<br/>(認可・ビジネスロジック)"]
DB[("業務 DB")]
end
subgraph AuthBox["認証基盤(置換前提)"]
Auth["認証基盤<br/>(認証・トークン発行)"]
AuthDB[("認証 DB")]
end
App -->|API| Backend
Admin -->|API| Backend
App -->|ログイン/登録| Auth
Admin -->|ログイン| Auth
Backend -. トークン検証 .-> Auth
Backend --> DB
Auth --> AuthDB- 会員アプリ: 会員登録・ログイン、会員証の取得・表示、チェックイン、ポイント・クーポン・抽選、予約、お知らせの閲覧。エンドユーザーが日常的に触れる唯一のインターフェース
- 管理画面: テナント・ショップ・会員・スタッフの管理と、ポイント・クーポン・お知らせ・予約(予約カレンダー、ショップ予約)の運用。運営・テナント・ショップ各スタッフの業務を支える運用UI
- 業務 API: 会員向け・運営向けのAPI、認可(所属・ロール)、業務ロジック、バッチ処理
- 認証基盤: アカウント発行、ログイン、トークンの発行・検証。会員・スタッフいずれの認証もここに集約
分割の意図
構成そのものより、「なぜこう分けたか」が設計の本体です。
- API とクライアントの分離: バックエンドは会員・会員証・ポイント・クーポンなどのリソースに対するAPI群を提供し、会員アプリ・管理画面はそれを利用するクライアントとして分離。APIとアプリを独立して開発でき、画面の見せ方の自由度が増し、将来的には別の作り手によるアプリ参入の余地も生まれる
- 認証と認可の分離: 「誰か」を判定する認証は認証基盤に、「何ができるか」を判定する認可は業務APIに分離。認証手段を置き換えても業務ロジックに影響しない構造にしている。認証基盤は仮実装とし、実運用では外部の認証サービスに置き換える前提
- 会員向けと運用向けの UI 分離: 利用者・利用頻度・求められる使い勝手が大きく異なるため、会員アプリと管理画面を別アプリケーションに分け、独立して進化できるようにしている
- データストアの分離: 認証情報(個人情報の中核)と業務データを別DBに置き、バックアップ・監査・将来の認証基盤分離の自由度を確保している
設計判断を記録に残す
「なぜこの構成・方針になっているのか」は、コードや個別の設計書からは読み取れません。重要な判断は ADR(Architecture Decision Record)として、判断の背景ごと記録しています。
実際に残している判断の例:
| 判断 | 背景の要点 |
|---|---|
| 主軸はバックエンド機能、フロントエンドはサンプル実装 | 価値の中心はAPI群。画面は差し替えられる前提で薄く保つ |
| 認証基盤は仮置きとし、本番は外部の認証サービスに寄せる | 認証は自作しないのが原則。開発を止めないための仮実装と割り切る |
| 機能要件は実装レイヤーを書かず、アクター主語の「できること」で記述する | 要件と設計の境界を守り、要件が実装に引きずられないようにする |
| スタンプカードは順序付きの「台紙」の列で管理し、有効な台紙は常に1枚とする | 紙のスタンプカードの運用(満了→次の台紙)をそのままモデル化する |
| 抽選(福引)はクーポンの仕組みの中で完結させる | 当選判定を同期・単一トランザクションにして整合性を単純に保つ |
ADR は1判断1ページの軽いドキュメントですが、「後から入ったメンバーが構成の理由を推測しなくて済む」「過去の判断を安心して覆せる(記録があるから)」という効果があります。
ドキュメントの層構造
要件 → 設計 → API仕様 の3層で管理し、それぞれの「正」を決めています。
| 層 | 内容 | 正(source of truth) |
|---|---|---|
| 要件 | なにがしたいか・どんな品質か | 要件ドキュメント |
| 設計 | どう実現するか(構成・DB・API方針) | 設計ドキュメント + ADR |
| API 仕様 | エンドポイントの詳細 | OpenAPI 定義(リファレンスは自動生成) |
API リファレンスを手書きせず OpenAPI 定義から自動生成することで、実装と仕様のずれを防いでいます。
つづきは 機能と画面 へ。
このサンプルの内容は、今後の見直しで変わることがあります。各機能の検討で使っている考え方は業務ノウハウに一般化して公開しています。
お問い合わせ
こんなアプリを作ってみたい、自分のお店に合わせて相談したい、という方はお気軽にご連絡ください。