Teeda Extension featuring Goya 〜内部設計〜
要件定義→外部設計→(アーキテクチャ)→内部設計→コーディング→単体テスト→結合テスト
今回から、数回に分けて内部設計について紹介していきます。
工程の位置づけ
システムがユーザに提供するものが、システム内部でどのように振舞うかを定義します。
- 各機能で、外部設計と実装を結びつけるもの(外部設計の検証にもなる)
- 機能横断的に呼び出されるもの
成果物
- UIモックアップ(更新)
- 外部設計で作成したUIモックアップに、idを追加する。
- CRUDマトリクス
- 機能毎にCRUDの処理内容をまとめる。操作シナリオとデータモデル(DB設計)の検証にもなる。
- 作成するのは手間がかかるが、試験のときのことを考えても作成しておくことをお勧めする。
- 業務ロジック設計
- 複雑な業務ロジックについて設計を行う(すべてのロジックについて行う必要はない)。主に、処理レシピとして書き出した内容が設計の対象となる。
- 共通機能設計
- Interceptor/Helper/Utilityに関する設計を行う。
設計では、どのような手法を利用しても構いません。設計/実装者が慣れた方法を取ることが良いでしょう。
共通機能を抽出する際の考え方
共通機能は、先に述べたInterceptor/Helper/Utilityに大別されます。それぞれの内容と抽出する考え方は、以下のようになります。
Interceptor
Helper
Utility
- 内容
- 機能横断的に呼び出されるが、DIする必要がないコンポーネント
- 抽出する際の考え方
- staticに呼び出すだけ
- 引数だけで戻り値が一意に決まり、状態などには因らない
- 例
- 文字列変換処理
*1:簡単な通知処理ならば、Interceptorとして実現できることもあります。条件によって送信先が変わるような場合は、Helperとして実装した方が実現しやすいでしょう