これは、Laravel フレームワークをつかったWebアプリケーションの Demo Projectです。
書籍「ユースケース駆動開発実践ガイド」に記載の手法を模倣してクラス設計をし、Laravel フレームワークの提供するMVC環境上で動作するコードを示します。
なお、当Projectは次のような 「Webエンジニア人材を教育する場面において有用な教材として活用できること」 という目的も併せ持って作成されています。
- Webエンジニア職への就業を希望するWeb開発未経験者が言語の習得を終えて開発演習に取り組むような場合に、指導者側ですぐに利用できる教材となること。
- Webエンジニア職の初級者を抜けて開発物のスパゲティコード化が気になり始めているエンジニアの中でも 「オブジェクト指向分析を伴って設計すること」にスパゲティ化回避の活路を見出した ような方へ、オブジェクト指向分析を伴ったアプリケーション設計の実践例を示すこと。
- 書籍「ユースケース駆動開発実践ガイド(ダグ・ローゼンバーグ、マット・ステファン共著)」を読んでみたけどICONIXの何が良いのかイマイチピンとこなかったような人へ、メリットを紹介できるような資料となること。
- Webや書籍等で様々提供されている「ドメインモデリングに基づいた参考実装」や「読者をDDD(ドメイン駆動設計)へ導くべく書かれた参考記事」をエンジニア教育の実践に用いる場合に、「MVCフレームワークによるWebアプリケーション」においてすぐに使えるテンプレートとなること。
Table of Contents
※注記
2021年10月28日時点では、以下に示す設計資料で定義されたユースケースのうち一部のみが実装されています。
未実装のユースケースについては、折を見て実装を行います。
- docs/UserAccountManagement/Required.md で、(仮想の)対象システムにおける一般ユーザアカウント管理機能に要求されている振る舞いをリストしています。(いわゆる「要求定義」を、ICONIXプロセスに反映させるためのリストとして分解したもの)
- docs/UserAccountManagement/01_メイン資料/一般ユーザアカウント管理機能_概念モデル図.png で、対象の問題領域(ドメイン)をモデリングしています。
- docs/UserAccountManagement/02_補助資料/補助資料.1_一般ユーザアカウントのライフサイクル.png で、このアカウント管理機能が組み込まれるシステム内での「一般ユーザ」のライフサイクルを示しています。
- docs/UserAccountManagement/03_pkg構成/PkgStructure.png で、各種ユースケースのクラス図で示された各々のクラスがどのようなパッケージ構成(=ディレクトリ構成)で配置されるのかを図示しています。
- docs/UserAccountManagement/01_メイン資料/システム管理操作/システム管理操作UseCase図.png で、このアカウント管理機能におけるシステム管理者向けのユースケースを図示しています。
- docs/UserAccountManagement/01_メイン資料/一般ユーザ操作/一般ユーザ操作UseCase図.png で、このアカウント管理機能における一般ユーザ向けのユースケースを図示しています。
- docs/UserAccountManagement/01_メイン資料/一般ユーザ操作/アカウント作成の申請をする/ ディレクトリには、ユースケース「アカウント作成の申請をする」に関する次の設計資料が収められています。
- ユースケース記述
- ロバストネス図
- シーケンス図
- クラス図
- GUIモック
- docs/UserAccountManagement/01_メイン資料/一般ユーザ操作/システムへログインする/ ディレクトリには、ユースケース「システムへログインする」に関する次の設計資料が収められています。
- ユースケース記述
- ロバストネス図
- シーケンス図
- クラス図
- GUIモック
- docs/UserAccountManagement/01_メイン資料/システム管理操作/システム管理コンソールへログインする/ ディレクトリには、ユースケース「システム管理コンソールへログインする」に関する次の設計資料が収められています。
- ユースケース記述
- ロバストネス図
- シーケンス図
- クラス図
- 次の要件を満たす環境を用意する。(dockerを使用できる場合は ucan-lab氏作成テンプレート の活用を推奨します)
- PHP: 8系
- composer: 2系
- MySQL: 8系
- git でローカルPC環境へ clone する。
- 前項のローカルgitリポジトリで demo ブランチを checkout する。
- phpunit によるテストを実行し、正常終了できることを確認する。
- MySQLと連携してWebサービスとして動作できる状態にする。(※環境構築の詳細手順まだ準備できていません。sorry!)
- 以後、 localhost:8000 でサービスが起動していると仮定して記述を進めます。
- 以下の各種操作を行う
- http://localhost:8000/
- HomeController:index の表示がされる
- 「Login」リンク、もしくは「Myデスク」リンクをクリックする
- http://localhost:8000/uam/login/input
- ログイン画面が表示される
- Email「sample@example.local」(passwordは任意入力)でログインを行い、 storage/logs/laravel.log に「入力されたメールアドレスを使用するユーザはいません」のエラーメッセージが表示される(今のところログイン画面へエラーメッセージ表示する実装はしていません)
- Email「hoge01@example.local」、password「hoge01TEST」でログインを行い、MyWorkController:index の表示がされる
- 「ログアウト」リンクをクリックし、遷移先の画面で「Home」リンクをクリックする
- http://localhost:8000/
- HomeController:index の表示がされる
- 「Sing Up」リンクをクリックする
- http://localhost:8000/uam/create-account/new
- アカウント作成の申請画面が表示される
- Email「hoge02@example.local」、password「hoge02TEST」で「新規アカウントを作成する」ボタンのクリックを行い、HomeController:index の表示がされる
- 「Login」リンク、もしくは「Myデスク」リンクをクリックする
- http://localhost:8000/uam/login/input
- ログイン画面が表示される
- Email「hoge02@example.local」、password「hoge02TEST」でログインを行い、MyWorkController:index の表示がされる
- 「ログアウト」リンクをクリックし、遷移先の画面で「Home」リンクをクリックする
- http://localhost:8000/
- HomeController:index の表示がされる
- 「管理者Login」リンク、もしくは「管理コンソール」をクリックする
- http://localhost:8000/uam/login/admin/input
- 管理者ログイン画面が表示される
- Email「adm01@example.local」、password「hoge01TEST」でログインを行い、SystemConsoleController:index の表示がされる
- http://localhost:8000/admin/index
- 「ログアウト」リンクをクリックし、遷移先の画面で「SiteTop」リンクをクリックする
- HomeController:index の表示がされる
- http://localhost:8000/
※実は上記の ⅱ. と v. の結果は、要件定義・設計の考慮漏れを含んでいます。
「申請中」のステータスであるにも関わらずログインできてしまっているのは、当初の想定とは違った挙動であり、
後ほど修正するつもりです。(要件を「申請中でもログインはでき、別の制限がある」と変えて修正を回避するのもありかも?)
※「テーマ」は「方針」と言い換えても良い。
書籍「 ユースケース駆動開発実践ガイド 」で紹介されている ICONIXプロセス に則って分析・設計を行っています。
ユースケース記述ごとにロバストネス分析を行い、そこからシーケンス図を描きつつ並行してクラス図を生成し、そのクラス図が示した構成を、言語やフレームワークをまたいで可能な限り共通に使います。
DDD界隈で語られることの多いアプリケーションアーキテクチャの中でも オニオンアーキテクチャ が示す考え方をいくつか参考にして取り入れています。
それにより、フレームワーク(UI層やInfra層やTest層)が何と差し替わろうともビジネスロジックが影響されない実装を行えます。
- ユースケースで表現されるビジネスロジックは、Java や PHP や Python といった各言語のピュアな言語機能のみによってテスト駆動で実装します。
- そのため、プロダクトに使用するフレームワークやサードパーティ製ライブラリの選定期限に猶予がもたらされます。
- このことは、特に社内の人材育成プログラムにおいては次のようなメリットを生むでしょう。
- フレームワークの実行環境がなんらかの事情で動かない場合でも、実装の話ができる。
- 使用するフレームワークを(比較等のため)実験的に差し替えることの難易度(ハードル)が下がる。
- 受講者が学習を希望する言語やフレームワークに応じて講師が模範解答などを用意する際に、講師が対象フレームワークに不慣れでも把握を焦らずに済む。
- ビジネスロジックを ユースケース層以降へ凝集するため、言語が同じならそれらは まさにそのまま 、また異なる言語でもクラス構成や属するメソッドの設計上のシグネチャ等はそのまま、 移植できます 。
- なお、システム全体の移植に際して書き直しが必要になるのは次の事項です。
- テストの記述
- データソースから集約オブジェクトへのマッピング
- プレゼンテーション層への値のマッピング
- とは言えこれらも、しっかりビジネスロジックをユースケース層以降へ凝集できていれば、それぞれのコーディングはとてもシンプルな作業になります。
- なお、システム全体の移植に際して書き直しが必要になるのは次の事項です。
- 例えば、現状の PHP向け実装 を踏襲したクラス構成で Java向けの実装も実現 できます
- ユースケース「アカウント作成の申請をする」
プレゼンテーション層
: 「氏名」「生年月日」の入力欄プレゼンテーション層
: エラーメッセージの表示
※上記で「プレゼンテーション層」の記述が指すのはMVCフレームワークの V(View) と C(Controller) のことです。
- アカウント作成申請時のメール送信
- アカウント作成申請時のemail文字列バリデーション