ライブラリモジュールパターンとは？
前回内容はこちら
ライブラリモジュール（Library Module） は、非 UI の共通機能やロジックを切り出し、複数のアプリから再利用できるモジュールです。
Foundation レイヤーに位置し、公開されたアクション・ブロック・構造体・エンティティを他モジュールから参照可能にします
ライブラリモジュールの2つのパターン（頻出）
ライブラリモジュールには拡張パターンとコネクタパターンの２つがあります。細かくみていきましょう。
拡張パターン
Extension（拡張）パターンは、外部API／ネイティブライブラリをIntegration Studioで扱い、再利用可能なActionとして公開するための基本構成です
コネクタパターン
コネクタパターンには下記2つのモジュールがあります。
- 外部APIのカプセル化に使用する拡張モジュール
- 正規化されたAPIをコンシューマに公開するラッパーモジュール
ライブラリモジュールの要素
ライブラリモジュールの要素についてLogic、Data、UI、Rolesの観点でそれぞれ見ていきます。含めることができる（できない）のはどれでしょうみたいな問題で出ることもあるのである程度覚えておきたいです。
Logic
- 正規化されたAPI
- 外部システムにマッピングされ利用可能な形式で情報を提供します
- 様々な例外を隠すための例外処理
- 外部連携サービスでのエラーを画面に反映させるのはシステム的に避けたいため、そういったものを適切にハンドリングすることで例外処理の中に隠すことができます
- SSO（シングルサインオン）やセッションロジックを処理するロジック
- 外部システムとの連携を可能にします。ただしAPIを使用するであろうコンシューマはインタラクションの仕組みを感知しません。
Data
- Structure
- 正規化されたAPIに対する呼び出しの入出力用
- Core以外のエンティティ
- 他サービスとの連携に役立つマップ上の点や参考情報のようなもの
UI
- UIウィジェット（カレンダーやアコーディオンなどの標準化されたコンポーネント）
- テーマのレイアウト、例外フロー
Roles
- 企業イントラネットなどの特定のドメインロールを入れることが可能
- 多いのは従業員やマネージャーなどを入れることで他のアプリでも似たロールを作成せずに済むので管理や変更の対象となるロールを共通ロールに絞ることができます
ライブラリに含められない要素
画面（Screens）はライブラリには含められません。
Foundation（基盤）用途に特化しているため、Consumerモジュールで独自に定義する必要があります。
APIの粒度（特にコネクタパターンの連携サービスで重要）
ここは公式講義の文言そのまんまになりますが過去テストにこのまま出ていることがあったみたいなので一応載せておきます。
例として大規模な外部システムと連携する場合を考えてみる
超大規模なSAPシステムでAPIが数百個ある場合連携サービス内に数百のAPIやストラクチャが作成される可能性があります。この場合は1つの大規模な連携サービスを複数に分割した方が便利かもしれないです。 例えば、金融、人事関連、リソース管理など機能領域別に連携を分割してみることでそれぞれの連携先は変わらないもののボトルネックへの一点集中を避けコンシューマへの影響を回避することができます。さらに機能領域で分けたためそれぞれのAPIを使用するユーザが分離されることでソリューション管理の容易化にも寄与することができます。
まとめと次回予告
体感そんなに出てるイメージなかったのですがネットで拾える問題とかにちらほら見るので一通り頭に入れて置けると安心だと思います。
次回は依存関係の強弱について学習していきます。
コメント