◯◯駆動開発というのは多くあり、その多くは設計やアーキテクチャに関する概念です。
以前読みました「.NETのクラスライブラリ設計 改訂新版」
全てのルールが、一般的なアプリ開発などで適応できるとは思えませんが、良い教えと悪い失敗が多くあり、ためになる一冊でした。
その中で重要度が大きいなと思った、「シナリオ駆動開発」というワードについて少しお話しします。
シナリオ駆動開発
「シナリオ駆動開発」とは、どこからでも使われうるようなクラスはどう作るのがいいのか、というお話です。
ユーザーは、そのクラスをどう使いたいの？
というお話。
例えば、
「アプリ内であるデータを使用するが、アプリには最初から入っておらず、サーバから取ってきて使用する、一度取ってきたら何度も取りに行かないようにストレージに保存して、次からはそこから使用する。」
という機能を作りたいケースを考えてみましょう。
要するにAssetBundleの話だと思っていただければ大丈夫です。
ドメイン駆動的考え方
必要な具体的機能は例えば以下のようなものになるでしょうか。
- データを読み込む
- ストレージに既にあるかチェックする
- ストレージから読み込む
- サーバから取ってくる
- ストレージに保存する
また、実際にはメモリ管理も行うでしょうが、一旦別の話なので無視します。
さて、この状況でクラスの責務をどう分けるのが正解でしょう。
答えを言ってしまうと、単一の正解はありません。場合によります。
上記5つ全部分けりゃいいじゃん！ と思うかもしれませんが、実際のところ、別に分けなくていい場合もあります。
機能としては上記5つは異なりますが、実際に使うときには将来的にも、絶対に、例外無く一緒に使われるならば、クラスを分ける意味は無いです。
変更容易性を高めるならば、将来の変更可能性を考慮すべきですが、そこを考えても変更はあり得ないなら、別にいいでしょう。
そして、その将来の変更可能性をどうやって判断するのかというのが、ドメインへの理解です。
ドメインへの理解こそが、そのプロジェクトで本当に適切な機能分解には不可欠ということです。
5つの機能と言いましたが、プロジェクトによってはもっと細かく分ける必要があるかもしれません。
例えば、ストレージに保存すると言っても、データの種類によって場所や、保存期間が違うかもしれないし、サーバから取ってくると言っても、全てのデータが同じサーバには無いかもしれません。
そういう場合は、データの所在を教えてくれるクラスを切り分けた方が良いでしょう。
そういう要件が無い場合でもデータの所在を取得する手段は用意するでしょうが、クラスを分けたりはしないですよね。
こんな感じで、クラスが持つべき責務というのに最適解はありません。
こういう話はやはりミノ駆動さんの話が良いですね。
シナリオ駆動的考え方
さて、ではシナリオ駆動ではどう考えるかという話です。
まず、シナリオ駆動という考え方は、特にドメイン駆動とは競合しません。
そもそも、アーキテクチャの考え方ではないんですね。
シナリオ駆動開発とは
使用者の目線で開発すること
です。
つまり、前述のドメイン駆動でも挙げたデータダウンロードの例でいうと、
データをメモリに展開し、使用したい人（クラス/メソッド）は、どう使いたいと思うか
というところから開発を始める手法となります。
C#で言えば、おそらく
var data = await AssetLoader.LoadAsync("名前とか、アセットを特定できる何か");
みたいにサッと書けたら使用者は嬉しいでしょうね。
また、不要になったら意識しなくてもメモリから解放されてくれれば尚良いでしょう。
その場合staticメソッドだと不都合があるかな。
事前に読み込むこともできてほしいですね。
ダウンロードする必要があるかのチェックも単体で使うかな。
などなど……
これを実現できるには何を公開すればいいかなぁと考えるのがシナリオ駆動開発です。
ここで必要なのは使用者の目線。
ドメイン駆動開発と同様、プロジェクトへの理解は欠かせませんね。
終わり
というわけで、シナリオ駆動開発っていい考え方だねというお話でした。
結局のところ、自分が作ったものがどのように扱われるのか、という、ユーザー目線
ここで言う「ユーザー」は、アプリのユーザーかもしれないし、クラスやメソッドのユーザーかもしれない
要するに将来の自分かもしれない
そして、こう言う、単一の正解が無いという難しさがあるため、ドメイン駆動開発や単一責任原則の大事さをプログラマに教えるには、自分で考える力を身につけさせるためにも 歴史ある地獄の炎上プロジェクトに叩き込むのが一番なのかもしれません。
