関心の分離について

学習の目的

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

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

はじめに

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

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

一緒にトレイルを進みましょう

エキスパートの説明を見ながらこのステップを実行したい場合は、次の動画をご覧ください。これは「Trail Together」(一緒にトレイル) シリーズの一部です。

関心の分離 (SOC)

クマの Codey は、「最も優れたコードは、キーボードから離れたところで書かれる」とよく言います。念入りな設計と見通しの成果が優れたコードであるとも言えます。コードを置く場所を計画するときは、このアドバイスを念頭に置いてください。道筋がわかっていれば、コード作業は楽になるでしょう。

複雑なコードは、適切に分けられない場合、手に負えなくなります。コードが複雑に混ざっていると、エラーが発生しやすく、管理や学習も難しくなります。他人が作成した、複雑にからまったコードをデバッグしたことはありますか? さらに、このような場合、新しい開発者が仲間に加わると問題が悪化します。アプリケーションのさまざまな部分で共通の計算およびプロセスを共有するモジュールまたはライブラリを作成することは、多くの場合、コード再利用の第一歩であり、もちろんよいことです。

SOC とコードの再利用の違い

SOC の場合、クラスの命名規則やコーディングのガイドラインを含む、アプリケーションの内部調整をあらかじめ検討する必要があります。このような計画が持続性を生み、ある程度、他人への説明にもなります。よいコードは物語を伝えます。コードの再利用の場合、複数の領域で必要となれば、すぐにコードの断片を移動する方法が一般的です。多くの場合、コードは、単純に MyUtil クラスやその他の汎用的な領域に配置されます。これでも大丈夫です。もちろん、コピーおよび貼り付けがお勧めです!

SOC の利点

大まかに言うと、アプリケーションには 3 つのものが含まれています。ストレージ、ロジック、さらに使用者が人であれ、他のアプリケーションであれ、やり取りする手段です。これらを分ける場合、アプリケーション内のレイヤーの定義から始めます。レイヤーそれぞれが独自の関心のセットを持ち、他のレイヤーおよびアプリケーション全体に対して責任を負います。SOC を適用するには、これらのレイヤーを慎重に考慮し、管理することが重要です。

• 進化。時を経て、テクノロジー、知識、要求 (機能と技術面の両方) が高まるにつれて、レイヤーを拡張、再編、場合によっては廃棄する必要があります。主たる例として、この 10 年の UI テクノロジーを考えてみてください。JavaScript フレームワークの数を数えたら、きりがありません。
  
• 影響の管理。レイヤーの変更または廃棄は、要求によって意図したものでない限り、他のレイヤーに過度な影響を与えません。
  
• 役割と責任。それぞれのレイヤーは独自の責任を持ち、その責任を満たさない、または超えることはできません。たとえば、別のテクノロジーまたはライブラリのためにクライアントテクノロジーまたはライブラリを廃棄することは、ビジネスロジックがなくなることを意味しません。それは別のレイヤーの責任であるためです。責任の境界線があいまいである場合、SOC の目的および価値は損なわれます。これはよいことではありません。
  

Salesforce プラットフォームには、宣言型 (ポイント & クリック)、および従来のコーディングという異なる 2 つの開発のアプローチがあります。いずれの方法も、単独または連携させて使用できます。標準 SOC レイヤーに対応する 2 つの方法を次に示します。

プレゼンテーション

• 宣言型: レイアウト、レコードページ、フロー、レコードタイプ、数式、レポート、ダッシュボード
  
• コーディング: Apex コントローラー、Visualforce、Lightning コンポーネント
  

ビジネスロジックレイヤー

• 宣言型: 数式、フロー、検証ルール、共有ルール、承認プロセス
  
• コーディング: Apex サービス、Apex カスタムアクション、非同期 Apex
  

データアクセスレイヤー

• 宣言型: データローダー、Salesforce Connect
  
• コーディング: SOQL、SOSL、Salesforce API
  

データベースレイヤー

• 宣言型: カスタムオブジェクト、項目、関係、積み上げ集計
  
• コーディング: Apex トリガー
  

Salesforce で SOC が不要なとき

Salesforce の主な利点の 1 つは、コードをまったく記述せずに、オブジェクト、項目、レイアウト、入力規則、ワークフロー、数式項目などを作成できる、宣言型開発モデルです。宣言型開発は、短時間ですみ、簡単です。また、ある程度の SOC が実装済みです。アプリケーションが非常にデータ中心である場合、アプリケーションの多くの部分を宣言型によって実現できます。車輪を作り直すのではなく、これを利用しましょう。

コードではないものの、宣言型開発で実現できる内容は、大部分がアプリケーションのアーキテクチャレイヤーです。これについては後で説明します。

Salesforce で SOC を使用するとき

アプリケーションがプロセス中心である場合、または複雑な計算、検証、リッチ UI を実装する場合は、Apex コードを採用しましょう。Salesforce には、トリガー、@AuraEnabled メソッドを含むクラス、API、Apex 一括処理、メールハンドラーなど、Apex コードを配置できる場所がたくさんあります。

コードの開発およびテストに多大な投資を投入できますが、保護の点で最も高い関心の対象はビジネスロジックです。ビジネスロジック作成のガイドラインは後で扱います。ここでは、Salesforce で SOC を使用するための次の事例を考慮してください。

• アプリケーションに別の UI を置換または追加する — UI と関係がなく、アプリケーションの挿入、更新、検証、計算機能に影響するコードのうち、書き直しまたは移植が必要な数を検討します。
  
• 一般向け API をロジックに提供する — API を実装するためにコールする既存のコードベースの部分がどこか確認します。@AuraEnabled メソッドを使用することが、API の適切な基盤となっていますか? (答えは、いいえです)
  
• Apex 一括処理でアプリケーションロジックを拡張する — 既存の UI を通じて、(少量の) インタラクティブなエクスペリエンスを継続的に提供する必要がある場合、規模にかかわらずユーザーに一貫した結果を提供するには、2 つの間でどのようにロジックを共有しますか?
  
• Visualforce コントローラーまたは @AuraEnabled メソッドの複雑なロジックに対応する — いずれかのコードが、ユーザーとの情報のやり取り以上の処理を行っていますか? Visualforce および Lightning コンポーネントを使用すると、クライアント開発用の SOC の形式であるモデル–ビュー–コントローラー (MVC) を通じてコードを分割できます。ただし、すべてのコードにコントローラーを使用しても、ビジネスロジックに関して SOC に従っていることは保証されません。
  
• 新しい開発者にとってコードベースの扱い方が簡単にわかるようにする — 新しい開発者が、新しいコードを配置したり、既存の動作を確認したりする場所を学ぶには、どれくらいの時間が必要ですか?
  

コードを記述した場所によっては、すでに上記のシナリオにうまく対応できる状態である可能性もあります。そうでない場合、またはこれを学習したい場合は、次の単元で扱います。次の表は、構築中のソリューションのサイズおよび範囲に基づいて、これらのパターンを使用するかどうかを判断するために役立ちます。

リソース

• 関心の分離 (Wikipedia)
• Martin Fowler’s Enterprise Architecture Patterns (Martin Fowler のエンタープライズアーキテクチャパターン)