みなさんこんにちは。
サンフランシスコで開催中のDremforce2015のレポートを現地からお届けします！

Dremforce開催日前日の予定がまるまる空いていましたので、

サンフランシスコ市内を存分に満喫してきました。

さて、今回は初日の9月15日のセッションの中より、Andrew Fawcettさんの
Apex Enterprise Patterns: Building Strong Foundationsについてご紹介します。

会場はMoscone West, Innovation Theaterという場所で立ち見だけでなく
床に座っている人もたくさんいて、なかなかの盛況ぶりでした。

　

セッションが始まるとまず、Apex Enterprise Patternsの紹介という形で悪い例のサンプルコードを提示し、例外処理の未実装やループ内でDML発行など、個々のダメな箇所を説明した上で全体的に拡張性を考慮していないことを指摘し、Apexのデザインパターンとして以下のレイヤーに分離しましょうと言っていました。

Service Layer ・・・プロセスやタスクのカプセル化
Domain Layer ・・・Validationロジック、トリガのラッピング、ビジネスロジックのカプセル化
Selector Layer ・・・参照系のデータベースアクセス

■Service Layer

Service Layerクラスは上図の四角の処理からコールされ
それぞれの処理に修正があっても他のプログラムには影響しないようになっています。

コントローラやApexBatchなどから共通的に呼び出される処理はここに該当するかと思います。
また、トランザクションの管理もこちらで行います。

■Domain Layer

Domain Layerでは、Validationとトリガのラッピングを行います。

サンプルソースにはValidationのメソッドとトリガのラッピングが同一クラスに記載されていましたが
実際はトリガーのラッパーは別途トリガーハンドラークラスを作成すると思います。

また、業務固有のビジネスロジックもDomain Layerで記述します。

■Selector Layer

　

Selector Layerでは参照系のデータアクセスを行います。
各検索条件のクエリーロジックはこちらで実装します。

以上のデザインパターンの説明だったのですが、
上述のトリガーハンドラや更新系のDAOクラスなども必要かと思いますので、
実際のプロジェクトで使用する際は適宜カスタマイズすることになると思います。

その他、Domain LayerとSelector Layerの各クラスはそれぞれ親クラスを継承する設計になっていますので
1つのServiceクラスの処理の中で動的にDomain LayerとSelector Layerを切り替える想定になっているようです。

こちらのデザインパターンにご興味のある方は
以下のURLで詳しく書いていますのでご確認くださいね。（英語ですが、、）

Apex Enterprise Patterns - Separation of Concerns
https://developer.salesforce.com/page/Apex_Enterprise_Patterns_-_Separation_of_Concerns

それでは2日目のレポートもお楽しみに！