ユースケース駆動開発をしてみた
これは2年位前に実践したときの記録です。
はじめに
新たにそこそこの規模のサービスを開始することになったので、設計の足がかりにと思って読んだ。今までは既存のサービスを改修する案件ばかりだったので、新しく１つ作るというのは初めてだった。
全部は読んでいない。後半は特にspringの説明が多くなってきたので興味が湧かなかったのと、アーキテクトなどはある程度もう決まっていたので、読んでも参考になりそうにないと思ったから。
実際読んだのは以下の章。
実践した感想
ドメインモデリング
やっている時に気をつけたこと
最初に作る時は特に、完成させようとしない。クラス図やER図とは別のものとして考える
所感
今の現場には用語集や設計図、モデルの図などの資料がかなり少なく（メンテされている資料はほぼなかった）、ドメインの概念を口伝や実装の中で教わることが多かったので、入った時にはかなり苦労したという経緯があって、実際にドメインモデリングをする時には、今回の開発対象以外のドメインも含めたドメインモデルを作成したが、今後の資料としてかなり使えるものができたと思う。
この本では、一旦ドメインモデリングをした後、後の工程で議論された内容を反映しつつ完成させていくということになっている。実際にやってみたところ、開発対象のサービスのドメインモデルが洗練されていき、チーム内で、概念的な部分で理解が一致していくのを感じた。話しながら「こういう構造だったのか」と気づく部分も多かった。
このドメインモデルを作る前は、「わからないものを開発する」という、何か薄闇の中で話し合っているような感覚だったが、一通り完成した後のチームの雰囲気は明るかったように思う。
ちなみに、事前に一人でドメインモデル作ってみてましたが、チームで最終的に合意したものとはかなりズレました。
ユースケースモデリング
やっている時に気をつけたこと
- ユースケース図を描いて、ユースケースを整理する。
- ユースケースを書くときは叙述的に書く。システムとユーザーのやり取りとして書く。どちらのイベントも省略しない。
- ユースケースを書くときはモデリングしたオブジェクトの名前を使う。
- 画面の名前を明らかにする。
所感
ユースケース図とユースケース記述は両方作った方が良いと思った。ユースケース記述を書いている間に、自分が何を書いているのか、今のユースケースはどのユースケースとつながっているのかを見失う瞬間がくるので、図があるとかなり楽。
ユースケースの記述をする前に、ある程度画面の絵を描いたりしたこともあり、画面の想像はできていたつもりだったが、システムの動きでわからないところや、描いていなかったが、存在する画面があることに気づいたりして有益だった。とりあえず書いてしまってあとでみんなで見直すぐらいが良さそうに思った。
画面の名前書くときは絶対「」をつけてたが、めんどくさくてもそうした方がよかった。主語はシステムorユーザーで統一し、システムが主語の文を書いたら、次はユーザーが主語の文を書く、というのを律儀に守ったことで、文章量はともかく、書く作業で迷ったり困ったりすることがなく、比較的楽だったと思う。
代替ケースを出すうちに、仕様の調整が必要な部分が見えてきたりしたので、代替ケースは必須だなと思った。
