読者です 読者をやめる 読者になる 読者になる

Teeda Extension featuring Goya 〜内部設計〜

要件定義外部設計(アーキテクチャ)内部設計コーディング単体テスト結合テスト

今回から、数回に分けて内部設計について紹介していきます。

工程の位置づけ

システムがユーザに提供するものが、システム内部でどのように振舞うかを定義します。

  • 各機能で、外部設計と実装を結びつけるもの(外部設計の検証にもなる)
  • 機能横断的に呼び出されるもの

成果物

  • UIモックアップ(更新)
  • CRUDマトリクス
    • 機能毎にCRUDの処理内容をまとめる。操作シナリオとデータモデル(DB設計)の検証にもなる。
    • 作成するのは手間がかかるが、試験のときのことを考えても作成しておくことをお勧めする。
  • 業務ロジック設計
    • 複雑な業務ロジックについて設計を行う(すべてのロジックについて行う必要はない)。主に、処理レシピとして書き出した内容が設計の対象となる。
  • 共通機能設計
    • Interceptor/Helper/Utilityに関する設計を行う。


設計では、どのような手法を利用しても構いません。設計/実装者が慣れた方法を取ることが良いでしょう。


共通機能を抽出する際の考え方

共通機能は、先に述べたInterceptor/Helper/Utilityに大別されます。それぞれの内容と抽出する考え方は、以下のようになります。

Interceptor
  • 内容
  • 抽出する際の考え方
    • 業務的な処理には、あまり関係しない処理である
    • 特定のレイヤーの呼び出しの前後で処理を行いたい
Helper
  • 内容
    • 機能横断的に呼び出されるが、パラメータ設定などのため、DI対象となるコンポーネント
  • 抽出する際の考え方
    • 事前にパラメータを設定したい
    • アプリケーション側から明示的に呼び出す必要がある
    • メール送信*1、ファイルアップロード/ダウンロード
Utility
  • 内容
  • 抽出する際の考え方
    • staticに呼び出すだけ
    • 引数だけで戻り値が一意に決まり、状態などには因らない
    • 文字列変換処理

*1:簡単な通知処理ならば、Interceptorとして実現できることもあります。条件によって送信先が変わるような場合は、Helperとして実装した方が実現しやすいでしょう