ダイコン時代の設計手法 - FDD
FDDはFeature Driven Developmentの略でシステムがユーザに提供する価値を
Feature(ユーザ機能)に分解してユーザ機能ごとに開発していきます。
ユーザ機能とは
- UI(バウンダリ)にどのようなイベント(コントロール)が起こってどのUI(バウンダリ)に遷移するのか
- コントロールがアクセスするエンティティ
が洗い出されます。
ロバストネス分析と平行して
- UIモック
- UI仕様書
- エンティティ仕様書
- ユーザ機能仕様書
を作成します。
用語がぶれてますがいずれ統一します。m(_ _)m
コントロールは、UI層のコントローラ、サービス層、永続化層に分解し、
UI層のコントローラの仕様はUI仕様書に記述し、
サービス層の仕様はユーザ機能仕様書に記述し、
永続化層の仕様は必要ならSQL仕様書に記述します。(いらんかも)
コントロールはロバストネス分析時には、リンクやボタンのクリックといった
イベントごとにVOの1センテンスで表現され、ユーザ機能に落とすときに、
事前条件・事後条件をつめていくイメージでいます。-> id:akonさん
良い機会だと思っているので、粒度・用語・設計手法はできるだけ
イメージをあわせましょ。
