7日目のゴールと視点の切り替え
7日目は
「コードを書く日」から
“自分の設計を評価して言語化する日”に切り替えます。
ログイン画面
一覧 → 詳細 → 編集
権限制御（擬似）
このミニ業務アプリを題材に、
設計力：自分のクラス設計を説明・批評できる
保守性：どこを変えれば何が変わるかを言葉で言える
実務思考：現場で使える“判断基準”として持ち帰る
ここまで持っていくのが、7日目のゴールです。
いま作っているアプリを「レイヤー」で言い直す
ドメイン層を言葉で説明できるか
あなたのミニ業務アプリには、だいたいこんな“世界”がいます。
User
Auth
Customer
CustomerRepository
Permission
これらは、画面や DOM を一切知らない「ドメイン層」です。
User は
「ログインしている人」を表すクラスで、
id・name・role・担当顧客などの情報と、isAdmin() や isStaff() のような“自分の属性に関する判断”を持ちます。
Auth は
「今誰がログインしているか」を管理するクラスで、
ログイン・ログアウト・現在のユーザー取得を担当します。
認証の方法（ID＋パスワード／メール＋パスワードなど）は
AuthUserStore のような別の責務に分けることもできます。
Customer は
「1件の顧客情報」を表すクラスで、
id・name・email などの状態と、
バリデーションや update のような“自分を正しい状態に保つ振る舞い”を持ちます。
CustomerRepository は
「顧客の集まり」を扱うクラスで、
一覧取得・1件取得・検索・保存などを担当します。
Permission は
「誰が何に対して何をしてよいか」を判断するクラスで、canViewList(user)canViewDetail(user, customer)canEditCustomer(user, customer)
のような“権限のルール”を一か所に集約します。
ここまでを、
自分の言葉で一文ずつ説明できるなら、
設計力はかなりいいところまで来ています。
アプリケーション層と UI 層を整理して言う
AppController は
「アプリ全体の流れ」を管理するクラスです。
どの画面を表示するか
どのタイミングでどの権限チェックをするか
どの Repository メソッドを呼ぶか
ログイン成功／失敗でどこへ遷移するか
といった“シナリオ”を担当します。
LoginView / ListView / DetailView / EditView は
「それぞれの画面の DOM とイベント」を担当するクラスです。
どの要素を表示／非表示にするか
どのボタンが押されたか
どの入力欄の値を Controller に渡すか
どのようにテーブルや詳細情報を描画するか
といった“見た目と操作の窓口”を担当します。
このレイヤー分けを
自分の口で説明できるようになっていることが、
7日間の集大成です。
設計力を“判断基準”として言語化する
「この処理はどのクラスの責任か？」を即答できるか
例えば、こんな処理を考えます。
名前が空ならエラーにしたい
メールアドレスの形式をチェックしたい
これは Customer の責任です。
「顧客として正しいかどうか」は、
顧客という概念のルールだからです。
この顧客を編集していいのは誰か？
admin は全件編集可
staff は担当顧客だけ編集可
これは Permission と User の責任です。
「誰が何をしてよいか」は、
権限という概念のルールだからです。
ログインに失敗したらログイン画面に戻す
ログインに成功したら一覧画面に遷移する
これは AppController の責任です。
「アプリとしてどう振る舞うか」は、
シナリオのルールだからです。
ログインボタンが押されたときに
入力欄の値を読み取る
これは LoginView の責任です。
「どの DOM から値を取るか」は、
画面の構造の話だからです。
こうやって、
「この if はどのクラスの事情を見ている？」
と自分に問い続けることが、
設計力そのものになります。
保守性を“変更シミュレーション”で確かめる
仕様変更を仮定して「どこを直すか」を言ってみる
ログイン方法を「メール＋パスワード」に変えたい。
どこを直すか？
Auth の login メソッド（あるいは loginWithEmailAndPassword）
AuthUserStore の検索ロジック
LoginView の入力欄（userId → email）
AppController のログイン呼び出し部分
ここ以外は触りたくないし、
触らなくて済むべきです。
一覧に「名前検索」を追加したい。
どこを直すか？
CustomerRepository に searchByName を追加
ListView に検索欄とイベントを追加
AppController の renderCustomerTable で
検索キーワードを Repository に渡す
権限ルールを
「staff も担当顧客なら編集可」に変えたい。
どこを直すか？
User に担当顧客情報を持たせる
Permission.canEditCustomer の中身を変更
Controller や View は、
Permission の結果を使うだけなので、
基本的には触らなくて済みます。
こういう“変更シミュレーション”をしたときに、
ここ、とここだけ
他はそのままでいい
と自信を持って言える構造になっているなら、
保守性はちゃんと高い状態です。
実務思考を“自分のルール”として持ち帰る
「現場で本当に役立つ視点」を3つに絞る
実務思考って、
難しい言葉に見えて、実はかなりシンプルです。
1つ目。
「UI とロジックを混ぜない」
DOM を触るのは View
画面の流れを決めるのは Controller
ビジネスルールはドメイン（User / Customer / Permission など）
この線を守るだけで、
画面デザイン変更・仕様変更・権限変更に強くなります。
2つ目。
「if 文の居場所を間違えない」
データの正しさ → ドメイン（Customer など）
権限の正しさ → Permission / User
画面の見せ方 → View / Controller
if が迷子になると、
あとから必ず自分が困ります。
3つ目。
「テストしやすい形にしておく」
Permission の判定
Customer のバリデーション
Auth のログインロジック
これらがブラウザ抜きで試せる構造になっているか。
なっていれば、その設計は実務的に強いです。
7日目の締め：あなたの言葉でまとめてみてほしいこと
最後に、あえて宿題を出します。
このミニ業務アプリの設計を、
あなた自身の言葉で、こうまとめてみてください。
このアプリのクラス構成はこうなっていて、
User / Auth / Customer / Repository / Permission / Controller / View が
それぞれこういう責任を持っている。
ログイン方法が変わっても、直すのはここだけ。
権限ルールが変わっても、直すのはここだけ。
画面デザインが変わっても、直すのはここだけ。
これを自分の言葉で言えた瞬間、
あなたはもう
「なんとなく書ける人」ではなく
“設計してから書く人”になっています。
あとは、このパターンを
別の題材（タスク管理、在庫管理、予約システムなど）に
何度か当てはめてみるだけです。
その繰り返しが、
本当に“実務で戦える設計力”を作っていきます。
