進行状況の追跡を始めよう
Trailhead のホーム
Trailhead のホーム

関心の分離について

学習の目的

この単元を完了すると、次のことができるようになります。

  • 関心の分離を採用するビジネス価値を説明する。
  • SOC を使用して、ユーザの要求やプラットフォームテクノロジの変化にソリューションを適応させる。
  • SOC を Force.com 開発に適用する。
  • SOC を適用するタイミングを判断する。

はじめに

ソフトウェアは、まるでヘアスタイルのように、時代によって変化および進化する生き物として、よく説明されます。単一細胞のアメーバのような「Hello World」プログラムから、エンタープライズレベルの複雑なソフトウェアまで、生き物の違いや幅広さは、そのままソフトウェアにもあてはまります。複雑な有機体は、特殊な目的のシステムを進化させます。骨、筋肉、臓器は、単位として機能しますが、同時に他のシステムと結びついて、全体に利益をもたらします。

それは、複雑なエンタープライズアプリケーションでも同じです。さまざまな関心を別々のシステムやレイヤに分けると、コードの流れがわかりやすくなり、管理が簡単になります。変更の発生時、他の領域への影響や回帰は最小限に抑えられ、より健全で適応性の高いプログラムに進化します。

関心の分離 (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 に適しているか?
1 ~ 2 人
  • よく把握できており、変化しにくい
  • 1 回限りのソリューション
  • 限られた数のオブジェクト
  • 標準 UI
  • 簡易な UI / トリガ
  • 一括処理モードなし
  • API なし
  • モバイルなし
通常は、いいえ
小から中 1 ~ 6 人
  • よく把握できているが、急速に進化させなければならない可能性がある
  • オブジェクトの数が増える、やりとりを処理する
  • 商品の成果物または長期間のプロジェクト
  • 標準 UI
  • 高度な VF / Lightning
  • 一括処理モード
  • API (ロードマップ上)
  • モバイル (ロードマップ上)
検討の価値あり
6 人を超える
  • 複数の顧客およびユーザ種別による範囲
  • 大量のオブジェクト
  • 顧客またはパートナーインテグレーションを伴う、中規模からエンタープライズサイズの市場向けの汎用的な商品またはソリューション
  • 開発チームの発展!
  • 標準 UI
  • 高度な VF / Lightning
  • 一括処理モード
  • 開発 / パートナー API
  • モバイルクライアント
  • 新しいプラットフォーム機能が使用可能、Chatter アクション!
非常に有効

リソース