関心の分離について
学習の目的
この単元を完了すると、次のことができるようになります。
- 関心の分離を採用するビジネス価値を説明する。
- SOC を使用して、ユーザーの要求やプラットフォームテクノロジーの変化にソリューションを適応させる。
- SOC を Force.com 開発に適用する。
- SOC を適用するタイミングを判断する。
はじめに
ソフトウェアは、まるでヘアスタイルのように、時代によって変化および進化する生き物として、よく説明されます。単一細胞のアメーバのような「Hello World」プログラムから、エンタープライズレベルの複雑なソフトウェアまで、生き物の違いや幅広さは、そのままソフトウェアにもあてはまります。複雑な有機体は、特殊な目的のシステムを進化させます。骨、筋肉、臓器は、単位として機能しますが、同時に他のシステムと結びついて、全体に利益をもたらします。
それは、複雑なエンタープライズアプリケーションでも同じです。さまざまな関心を別々のシステムやレイヤーに分けると、コードの流れがわかりやすくなり、管理が簡単になります。変更の発生時、他の領域への影響や回帰は最小限に抑えられ、より健全で適応性の高いプログラムに進化します。
一緒にトレイルを進みましょう
エキスパートと一緒にこの手順を進めますか? 次の動画をご覧ください。これは「Trail Together」(一緒にトレイル) シリーズの一部です。
関心の分離 (SOC)
クマの Codey は、「最も優れたコードは、キーボードから離れたところで書かれる」とよく言います。念入りな設計と見通しの成果が優れたコードであるとも言えます。コードを置く場所を計画するときは、このアドバイスを念頭に置いてください。道筋がわかっていれば、コード作業は楽になるでしょう。
複雑なコードは、適切に分けられない場合、手に負えなくなります。コードが複雑に混ざっていると、エラーが発生しやすく、管理や学習も難しくなります。他人が作成した、複雑にからまったコードをデバッグしたことはありますか? さらに、このような場合、新しい開発者が仲間に加わると問題が悪化します。アプリケーションのさまざまな部分で共通の計算およびプロセスを共有するモジュールまたはライブラリを作成することは、多くの場合、コード再利用の第一歩であり、もちろんよいことです。
SOC とコードの再利用の違い
SOC の場合、クラスの命名規則やコーディングのガイドラインを含む、アプリケーションの内部調整をあらかじめ検討する必要があります。このような計画が持続性を生み、ある程度、他人への説明にもなります。よいコードは物語を伝えます。コードの再利用の場合、複数の領域で必要となれば、すぐにコードの断片を移動する方法が一般的です。多くの場合、コードは、単純に MyUtil クラスやその他の汎用的な領域に配置されます。これでも大丈夫です。もちろん、コピーおよび貼り付けがお勧めです!
SOC の利点
大まかに言うと、アプリケーションには 3 つのものが含まれています。ストレージ、ロジック、さらに使用者が人であれ、他のアプリケーションであれ、やりとりする手段です。これらを分ける場合、アプリケーション内のレイヤーの定義から始めます。レイヤーそれぞれが独自の関心のセットを持ち、他のレイヤーおよびアプリケーション全体に対して責任を負います。SOC を適用するには、これらのレイヤーを慎重に考慮し、管理することが重要です。
- 進化。時を経て、テクノロジー、知識、要求 (機能と技術面の両方) が高まるにつれて、レイヤーを拡張、再編、場合によっては廃棄する必要があります。主たる例として、この 10 年の UI テクノロジーを考えてみてください。JavaScript フレームワークの数を数えたら、きりがありません。
- 影響の管理。レイヤーの変更または廃棄は、要求によって意図したものでない限り、他のレイヤーに過度な影響を与えません。
- 役割と責任。それぞれのレイヤーは独自の責任を持ち、その責任を満たさない、または超えることはできません。たとえば、別のテクノロジーまたはライブラリのためにクライアントテクノロジーまたはライブラリを廃棄することは、ビジネスロジックがなくなることを意味しません。それは別のレイヤーの責任であるためです。責任の境界線があいまいである場合、SOC の目的および価値は損なわれます。これはよいことではありません。
Force.com プラットフォームには、宣言型 (ポイント & クリック)、および従来のコーディングという異なる 2 つの開発のアプローチがあります。いずれの方法も、単独または連携させて使用できます。標準 SOC レイヤーに対応する 2 つの方法を次に示します。
プレゼンテーション
- 宣言型: レイアウト、フロー、レコードタイプ、数式、レポート、ダッシュボード
- コーディング: Apex コントローラー、Visualforce、Lightning コンポーネント
ビジネスロジックレイヤー
- 宣言型: 数式、フロー、検証、ワークフロー、共有ルール
- コーディング: Apex サービス、Apex カスタムアクション
データアクセスレイヤー
- 宣言型: データローダー
- コーディング: SOQL、SOSL、Salesforce API
データベースレイヤー
- 宣言型: カスタムオブジェクト、項目、関係、積み上げ集計
- コーディング: Apex トリガー
Force.com で SOC が不要なとき
Force.com の主な利点の 1 つは、コードをまったく記述せずに、オブジェクト、項目、レイアウト、入力規則、ワークフロー、数式項目などを作成できる、宣言型開発モデルです。宣言型開発は、短時間ですみ、簡単です。また、ある程度の SOC が実装済みです。アプリケーションが非常にデータ中心である場合、アプリケーションの多くの部分を宣言型によって実現できます。車輪を作り直すのではなく、これを利用しましょう。
コードではないものの、宣言型開発で実現できる内容は、大部分がアプリケーションのアーキテクチャレイヤーです。これについては後で説明します。
Force.com で SOC を使用するとき
アプリケーションがプロセス中心である場合、または複雑な計算、検証、リッチ UI を実装する場合は、Apex コードを採用しましょう。Force.com には、トリガー、Visualforce コントローラー、API、Apex 一括処理、メールハンドラーなど、Apex コードを配置できる場所がたくさんあります。
コードの開発およびテストに多大な投資を投入できますが、保護の点で最も高い関心の対象はビジネスロジックです。ビジネスロジック作成のガイドラインは後で扱います。ここでは、Force.com で SOC を使用するための次の事例を考慮してください。
- アプリケーションに別の UI を置換または追加する — UI と関係がなく、アプリケーションの挿入、更新、検証、計算機能に影響するコードのうち、書き直しまたは移植が必要な数を検討します。
- 一般向け API をロジックに提供する — API を実装するためにコールする既存のコードベースの部分がどこか確認します。Visualforce コントローラーのアクションメソッドは、API に適した土台を使用していますか? (答えは、いいえです)
- Apex 一括処理でアプリケーションロジックを拡張する — 既存の UI を通じて、(少量の) インタラクティブなエクスペリエンスを継続的に提供する必要がある場合、規模にかかわらずユーザーに一貫した結果を提供するには、2 つの間でどのようにロジックを共有しますか?
- Visualforce または Lightning コンポーネントコントローラーの複雑なアクションメソッドに対応する — いずれかのコードが、ユーザーとやりとりする情報を処理する以外に対応していますか? Visualforce および Lightning コンポーネントを使用すると、クライアント開発用の SOC の形式であるモデル–ビュー–コントローラー (MVC) を通じてコードを分割できます。ただし、すべてのコードにコントローラーを使用しても、ビジネスロジックに関して SOC に従っていることは保証されません。
- 新しい開発者にとってコードベースの扱い方が簡単にわかるようにする — 新しい開発者が、新しいコードを配置したり、既存の動作を確認したりする場所を学ぶには、どれくらいの時間が必要ですか?
コードを記述した場所によっては、すでに上記のシナリオにうまく対応できる状態である可能性もあります。そうでない場合、またはこれを学習したい場合は、次の単元で扱います。次の表は、構築中のソリューションのサイズおよび範囲に基づいて、これらのパターンを使用するかどうかを判断するために役立ちます。
| ソリューションまたはコードの基本サイズ | 開発者の数 | 要求の範囲 | クライアントタイプとやりとりの数 | SOC に適しているか? |
|---|---|---|---|---|
| Small (小) | 1 ～ 2 |
|
|
通常は、いいえ |
| 小から中 | 1 ～ 6 |
|
|
検討の価値あり |
| Large (大) | > 6 |
|
|
非常に有効 |
