コントロール分析
コントロール分析、いろいろなフィードバックを元に
考え直しました。
id:marrowさんやid:akonさんの考えを取り込んでます。
以前は、バウンダリに属するコントロールを1つにまとめ、
エンティティに関連するロジックはDaoにまとめ、
シナリオ分析を通じて、共通的なロジックがあったら
共通ロジックに抽出するという方法で、割とオーソドックスな
方法だと思うのですが、最初にクラスを抽出するところが
人によってまちまちな結果になって混乱する場合もあるようです。
特に共通ロジックのところが。
で、考え直しました。
最初に抽出されているコントロールは、Whatをあらわしています。
次に必要なのは、どのようにして(How)実現するかです。
Howはユーザ機能で表します。
FDDではユーザ機能は、<オブジェクト><結果><アクション>で
あらわしますが、VO(〜を〜する)となにが違うのか良く分かってません。
これまでと同様にVOで表すで良いだろうと思ってます。
いよいよ、コントロールをユーザ機能に分解します。
ユーザ機能は、これ以上分割することのできないアトミックな
ものになるまで分解します。
そうすると、ユーザ機能は、アトミックなものとアトミックなものの
フロー制御をするものに分かれるでしょう。
コントロールのユーザ機能への分解は、シナリオごとに行います。
シナリオは、
- しなければいけない
- ならばできること
- 例外
のケースについて分析します。
これがおわるとコントロールのすべてのユーザ機能(Responsibility)が
洗い出されたことになります。
次にResponsibilityをクラス(interface)に割り当てていきます。
コントロール層のクラスは次のように分類されます。
- 業務ロジック(*Logic)
- 補助ロジック(*Support)
- Dao(*Dao)
業務ロジックはバウンダリごとに作成します。*の部分はバウンダリを
表す名前が入ります。
Daoはエンティティごとに作成します。*の部分はエンティティを
表す名前が入ります。
永続化に関係ないけど、エンティティに関係するロジックも
Daoに含めた方がいいと思ってます。
Daoを使う側からすると永続的かどうかは関係ないためです。
業務ロジックにもDaoにも含まれないResponsibilityは
補助ロジックになります。*の部分は、VOのO(目的語)を
表す名前が入ります。
ResponsibilityをClassに割り当てると同時にClassにCollaboratorも
割り当てます。
例えば、Responsibility aaaがbbbを呼び出していて、
aaaがFooクラスに割り当てられ、bbbがBarクラスに割り当てられた場合は、
FooのCollaboratorにBarを割り当てます。
依存関係は次のようになります。
バウンダリ層が呼び出していいのは業務ロジックだけです。
業務ロジックが呼び出していいのは補助ロジックとDaoです。
補助ロジックは他のロジックに依存しません。
が呼び出していいのは補助ロジックとDaoです。
Daoも他のロジックに依存しません。
先にクラスを抽出するのではなく、ユーザ機能を洗い出してから、
役割に応じてクラスを割り当てるようにしたということですね。
なんか、FDDとCRCがいりみだれてますが、まぁいいか。
