はじめに
前回に引き続き、モデリングのオフライン勉強会に参加してきました。 第二回である今回は、前回作成した「図書管理システムの書籍貸出機能」を元に、下記をテーマにワークショップを行いました。
- 前回作成したモデルのリファクタリング
- 前回モデルを元にした書籍返却ユースケースのモデリング
- 作成したモデルに対し、「延滞中の会員には貸出しない」という要件を追加
- 上記モデルを元にしたパッケージ・クラス設計
これらを、ICONIXプロセスベースに分析・設計しました。 今回も色んな学びがあったのでメモでまとめます。
成果物
※ 写真は最終形態のもの
パッケージ図
シーケンス図
やったこと
- 前回の勉強会で作成した図書館貸出機能モデルのリファインメント
- 1をベースにした返却機能のモデリング
- 2への「延滞」という概念の追加
気づき・学び
シーケンス図を書く時は目的の粒度を意識する
- 前回の勉強会で作成したシーケンス図を後から見直すと、本来そのエンティティが持つべき操作をシステムが担ってしまっていたり、操作の粒度がばらばらになってしまっていた。
- シーケンス図はどのモデルにどの処理を委譲しているかを図式化できるが、その図の性質上どのモデルがどの責務を持つかということを意識しづらい。
- 今回は単一責務を意識し、エンティティに割り当てる操作の目的を構造化しながらシーケンス図を書いてみることにしたが、目的の粒度に合わせてシーケンス図を作成することができた(ように思う)
詰まったらいったん落ち着いて俯瞰してみる。物理的にも精神的にも
- 何かに詰まっている時は、コアな課題だけ見ていても絶対解決しない。答えは今注目している部分にはないことが多い。
- そういう時は一旦休憩挟む。もしくは、意識して俯瞰的に見るようにしてみる。意外と物理的に遠ざかってみたりすると別の発見があったりした。
- もしくは、一旦何らかの形で片づけてしまって先に進むのもあり。別の部分に目を向けると問題を構造化でき、解決策が浮かぶこともあった。
その他
- ドメインにも属さないけど、システムから直接線が伸びるのに違和感がある操作がドメインサービスかも？後日検討することに
- 最初は「貸出詳細」に貸出状況という状態フィールドを持っていたけれど、返却が登場したことで自然と状態フィールドがいらなくなった。意識はしてないけどイミュータブルデータモデル的な考え方になった？
- 貸出ルールは現時点だと実装クラス単体で運用しているが、今後の拡張性のことを考えるとインターフェースを設けた方がいいかもしれないという話になった
さいごに
今回はシーケンス図作成までかなりてこずったが、シーケンス作ってクラス図に落とし込んだら、すんなりパッケージングが出来てしまったという感じだった。ちょっと再検討が必要そうな部分もあるが、集約ごとのエンドポイントも1集約1クラスという構図を作れているように思う。 せっかくここまで作れたので、実際にコード書いてみてどんな問題があるのか検証してみようと思う。
