勉強しながらLaravel Modulesとクリーンアーキテクチャ、DDDを用いて個人開発をしてみる。
tksとりあえず気になる技術を使って、個人開発を進めてみようと思います。
- DDD
- Clean Architecture
- ユースケース駆動開発
- テスト駆動開発
- モジュラモノリス
とか気になる技術とか考え方？みたいなものを使って実装をしてみます。
tksとりあえず対象ドメイン
今回は、会社で問題になっている『アカウント管理』についてをドメインとして開発を行なっていこうと思います。
社内にて、 『誰にどのログイン情報（以下アカウント情報とします）を共有したのか』 把握ができていない状態です。
スプレッドシートなどで管理をしているのですが、ここも更新するのには一苦労であるように思います。
実際に僕は全てのアカウント管理をしていないのですが、一部アカウント情報は管理をしている状態です。
そこで、面白そうだなと思ったので、自分ならコードを書いてどう解決するかを考えていきます。
ドメイン駆動設計に関する補足
まず、ドメインはソフトウェアを適用する業務領域のことを指します。
会社には、様々な業務があります。
- 人事関係の業務
- 会計関係の業務
- 会社ごとの競争優位性のある事業
など、様々な事業があると思います。その中で、ソフトウェアを適用する業務領域のことをドメインと言います。
ドメイン駆動設計は、そのドメインの知識に焦点を当てて設計を行う手法のことだと思います。
実際に
では、事業活動の分析から業務知識を噛み砕く話が一番最初に出てきています。このように業務知識をもとに設計を行なっていく手法のことを、おそらくドメイン駆動設計というのではないかと思っています。
tksとりあえず業務分析をやってみる
ここからは、書籍を見て実際に手を動かしてみようと思います。
まずは業務分析についてです。
書籍ドメイン駆動設計をはじめようでは、業務領域について
- 中核業務
- 補完業務
- 一般業務
の3つに分けられています。それぞれ違いは
| 業務 | 意味 |
|---|---|
| 中核業務 | ここは会社が競争優位性を確保している？もしくは確保したい業務領域のことをさしています |
| 補完業務 | ここは、競争優位性はないものの、中核業務を支える、運勢するにあたってなければならないものです |
| 一般業務 | ここは、他社など会社を運営する上で必要なものということだと思います |
このような違いになっています。
今回で言うと、
| 業務種別 | 内容 |
|---|---|
| 中核業務 | 貸与管理 |
| 補完業務 | 従業員管理、アカウント管理 |
になるのかなと思います。
ざっくりとイベントみたいなものを思い浮かべると
- 従業員が入ってくる
- 従業員に必要なアカウント情報を貸与する
- 従業員はそれを参照して業務を行う
みたいな流れになると思うので、開発の流れとしては
- 従業員管理
- アカウント管理
- 貸与管理
みたいな流れになるのかなと思います。とりあえず先の話は置いておいて、続きをやっていきます。
会社の中には、様々な従業員がいます。
- 管理者
- 従業員
- アルバイトやインターン生
など、様々な従業員がいます。
また、これと同じで様々なアカウント情報も抱えています。
管理者を除いて、従業員やインターン/アルバイトは知っている従業員情報もあれば、知らない従業員情報もあります。
従業員について
従業員といっても
- 社長
- 管理職
- 従業員
- インターン / アルバイト
と分かれています。うちの会社の性質上管理職や社長がアカウントを発行し、それを従業員が閲覧すると言うケースがほとんどです。
また、従業員がインターン生やアルバイトに情報共有をすることもあります。
これをシステマチックに表現すると
- アカウントを発行、更新、削除するのは基本社長か管理者
- 従業員はアカウント情報をインターン生やアルバイトに共有する
と登録更新削除できる人と、共有する役割と、閲覧のみできる3種類のユーザーに分けることができると思います。図式化すると
| ポジション | できること |
|---|---|
| 社長、管理職 | アカウントの発行、編集、削除、閲覧と権限付与が可能 |
| 従業員 | アカウントの閲覧と、権限付与ができる |
| インターン / アルバイト | アカウントの閲覧ができる |
と言うふうに出来ると思います。
アカウント情報
これはシンプルに、アカウント情報です。
- メールアドレス（今のところIDだけのサイトに遭遇していない）
- パスワード
- アカウントタイプ
- 備考
とかがあれば大丈夫なような気がしています。
tksとりあえず何から作るか考える
今回作るソフトウェアで解決したいものは 『誰にどのログイン情報（以下アカウント情報とします）を共有したのか』 これを把握することです。
貸与管理が今回の中核ドメインではありますが、0から作る以上このドメインは
- 従業員
- アカウント
これらがないと成り立たない状態になると思います。そこで今回は
- 従業員管理
- アカウント管理
- 貸与管理
この順番で作っていこうと思います。
tks従業員管理ドメインのモデリングをしてみる
ここからは、書籍ユースケース駆動開発実践ガイドを参考に、モデリングを進めていこうと思います。
この書籍では、モデリングのフェーズにて
- ドメインモデリング
- ユースケースモデリング
がされているため、これに則って開発を進めていこうと思います。
また、こちらと並行して
も参照しながら、開発を進めていきたいな〜と思っています。
とりあえず従業員管理のドメインモデリングからやるぞ
以下、ドメインモデリングガイドラインを参照します。
ドメインモデリングのガイドライントップ10
- 現実世界のオブジェクトに焦点を合わせなさい
- オブジェクト同士の関係を表現するために、汎化（is-a）関係および集約（has-a）関係を利用しなさい。
- 最初のドメインモデリングにかける時間は2時間に限定しなさい。
- 問題領域中の主要な概念を中心にクラスを構成しなさい。
- ドメインモデルをデータモデルと勘違いしてはなりません。
- オブジェクト（単一のインスタンスを表現する存在）とデータベースのテーブル（モノの集合を含む存在）とを混同してはいけません。
- ドメインモデルをプロジェクトの用語集として使いなさい。
- 名前が曖昧になることを避けるため、ユースケースを書く前にドメインモデルを書きなさい。
- 最終的なクラス図が、ドメインモデルと正確に合致することを期待してはいけません。しかしこの2つは、何らかの形で相似の関係にあるはずです。
- ドメインモデルには、画面やその他のGUI固有の部品クラスを配置してはいけません。
色々となんかドメイン駆動設計を感じるところが多いですね。
ドメインモデルをプロジェクトの用語集として使いなさい。
これは、ドメイン駆動設計でいうところのユビキタス言語が似た意味になるんですかね。
従業員管理の要求を考える
このドメインは、従業員を爆誕させるところから、次のレベルに行く（悲しいですがやめてしまう）までのライフサイクルを管理するドメインです。
その従業員情報は、登録することもあれば、名前などが変わったりして更新されたり、一覧で検索をしたり、削除されたりと、CRUDみたいな感じで色々と要求があります。
また、従業員と一言で言っても、その中には
- 社長
- 管理職
- 従業員
- アルバイト / インターン
などがあります。これから、従業員には権限みたいなものがあるのがわかります。
次に、現実世界で従業員に起こるイベントを考えてみます（ちょっとイベントソーシングもどきをやってみたい）。
多分この4つのイベントが、一番最初に思いついたイベントです。実際にここからイベント同士を順番っぽく並べ替え、コマンドとかを足してみます。
やはりライフサイクルの最初は登録からなので、登録を一番左に持ってきています。
また、従業員登録と同時にアカウント情報も登録を行いたいです。従業員はこのアカウント情報を使ってログインすると想定します。
パスワードは仮パスワードを発行して、ユーザーにパスワードを入力してもらう仕組みにします。
また、従業員メールアドレスのみは会社で一人一つであって、重複はしないので、そのイベントも追加してみました。
おそらくこれで、アカウント登録に関するイベントソーシングはできたと思います。
ここからは、実装する上で必要になったらどどん追加していこうと思います。
イベントソーシングから読み取れるドメインモデル
ここからは、イベントソーシングをもとに読み取ったドメインモデルを見ていきます。