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

Teeda Extension featuring Goya 〜アーキテクチャ【レイヤー構成】〜

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


今回はアーキテクチャについてです。
レイヤー構成について、3パターンほど私が考える案を紹介します。
コンポーネントの役割については、別途説明したいと思います。

Full Pattern

  • 特徴
    • 大規模アプリケーション向け。
    • コンポーネントを最も細分化したパターン。画面とロジックを分担して共同開発したり、フロー制御や他システム連携が多かったりするシステムに向く。
    • Serivceがトランザクション境界となる。
  • レイヤー構成
    • プレゼンテーション層
      • Action、Page、Dto
    • サービス層
      • Service、Dxo
    • ドメイン層
      • Logic、Dao、Entity

Middle Pattern

  • 特徴
    • 中規模アプリケーション向け。
    • 画面ロジックとドメインロジックを2つのレイヤーに集約させたパターン。大抵のシステムは、このパターンで十分なケースが多い。
    • プレゼンテーションロジック(表示の切替、初期値の設定など)はAction、ドメインロジック(業務自体に関連する処理)はLogicに記述する。
    • Dxoは、データオブジェクトの変換を行うだけなので、プレゼンテーション層に位置づけている。
    • Actionがトランザクション境界となる。
  • レイヤー構成
    • プレゼンテーション層
    • ドメイン層
      • Logic、Dao、Entity

Lightweight Pattern

  • 特徴
    • 小規模アプリケーション向け。
    • 画面とDBテーブルが1対1で、ロジックはDaoを呼び出すだけ、というシステムに向く。
    • ロジックは、ほぼプレゼンテーションロジックだけになるため、Pageに集約してしまう。Pageだけでは1クラスあたりの規模が大きくなってしまい、見通しが悪くなるようならば、PageとActionを分けても良い。
    • Pageのdo〜メソッド(もしくはAction)がトランザクション境界となる。
  • レイヤー構成
    • プレゼンテーション層
    • ドメイン層
      • Dao、Entity