執筆：Adobe、シニアテクニカルアーキテクト、Tony Evers
グローバルリファレンスアーキテクチャ実装手法
作成対象：
- 初心者
- 中級
- 開発者
- ユーザー
- リーダー
Adobe Commerceでコードの再利用を最適化する方法はいくつかあります。 これらの 4 つの実装手法にはそれぞれ独自のメリットがあります。 この記事の例は、単純なものから複雑なものへと順番に並べられています。 プロジェクトと今後のロードマップに最適な戦略を選択します。 ある戦略から別の戦略への移行は、時間がかかる場合があります。
グローバル参照アーキテクチャを使用するタイミング
グローバル参照アーキテクチャは、所有するインスタンスの数に応じて役立つ場合があります。 インスタンスは、独自のデータベースを使用したAdobe Commerceのスタンドアロンインストールです。 実稼動データベースの数をカウントして、所有するインスタンスの数を把握します。 複数のインスタンスを維持する場合、またはこのシナリオが今後予想される場合は、グローバル参照アーキテクチャのメリットを享受できます。 インスタンスが共有する機能が多いほど、グローバル参照アーキテクチャによってより多くの価値が追加されます。
これらのシナリオのいずれにおいても、Adobe Commerceの複数のインスタンスを使用して探索することをお勧めします。
- 異なるストア所有者：複数のストア所有者のコードを保持し、それぞれに独自のストアがある場合、個々の要件を効果的に維持するために、別々のインスタンスが必要になる可能性があります。
- 各国の規制への準拠：特定の規制では、顧客データを特定の地域内に保存する必要があります。 このような場合、これらの規制に確実に準拠するには、別個のインスタンスが不可欠です。
- 地理的リージョン間での運用の相違：複数のリージョンで運用すると、メンテナンススケジュールや要件が異なる場合があります。 別々のインスタンスを使用すると、これらのバリエーションを効率的に柔軟に管理できます。
- 高輝度Flash販売：大規模なフラッシュ販売を行う店舗では、サーバの性能の最適化が求められることが多くあります。 個別のインスタンスによって提供される専用インフラストラクチャにより、このような需要の高い時期に最適なパフォーマンスが確保されます。
- ブランドまたは国の重要な違い：ブランドまたは国の違いが大きい場合、単一のインスタンスを使用すると、一部のブランドまたは国でのみ使用されるコードになります。 インスタンスを分離すると、不要なコードを必要としないブランドや国から不要なコードを排除して、パフォーマンスと安定性を向上させることができます。
グローバル参照アーキテクチャパターン
「GRA パターンなし」の横には、GRA パターンの 4 つのスタイルがあります。
GRA パターンの
GRA パターンなし
GRA パターンを使用しない場合、各Adobe Commerce インスタンスは一意のアプリケーションです。 あるインスタンスから別のインスタンスに手動でコードを移動する場合以外は、コードを再利用する必要はありません。 これらのコピーは常に発散します。 各インスタンスに同じ変更を加えても、期待どおりに動作することを確認するのは大変な作業となる場合があります。 このシナリオでは、3 つのインスタンスが 1 つのインスタンスの 3 倍のメンテナンス作業を必要とします。
分割 Git GRA パターン
このパターンは、開発用の Git リポジトリと、インスタンスごとに 1 つの Git リポジトリで構成されます。 インスタンス内の各ファイルは、いずれかの開発リポジトリに保持されます。 彼らは、全体の GRA を形成する編組として一緒に来る。 コードの各行は、単一の開発リポジトリにのみ存在し、編組技術を使用してインスタンスにインストールされるので、コードが再利用されます。
バルクパッケージの GRA パターン
Adobe Commerceのコアモジュールとサードパーティモジュールは、Composer リポジトリを介して直接インストールされます。 Git リポジトリは、Composer リポジトリとして使用できます。 このパターンでは、GRA 共有コードベース全体が 1 つまたは複数の Git リポジトリにホストされ、Composer を通じてインストールされます。 主な特徴は、複数のモジュール、言語パックまたはテーマが 1 つのコンポーザーパッケージでホストされ、開発を簡素化できることです。
別個のパッケージの GRA パターン
各Adobe Commerce モジュール、言語パックまたはテーマは、別々のコンポーザーパッケージとしてインストールされます。 カスタマイズごとに独自の Git リポジトリがあります。 これにより、インスタンスの構成が極めて柔軟になり、信頼性の高い Composer 依存関係管理が実現します。 パフォーマンスを最適化するために、すべてのパッケージが 1 つの private composer リポジトリにミラーリングされます。
モノレポ GRA パターン
開発はすべて 1 つのコードリポジトリで行われます。 自動処理では、新しいバージョン用のパッケージが生成され、コンポーザリポジトリに公開されます。 このパターンは、バルクパッケージアプローチの低い開発オーバーヘッドと、個別パッケージアプローチの柔軟性を組み合わせたものです。 また、モノレポジパターンは、自動化された機能テストを実行する場合にも最適です。
GRA パターンの選択
GRA パターンの選択は、プロジェクトの複雑さ、柔軟性の必要性、開発チームの適応能力を評価することで行われます。
Adobe Commerceの経験が少ないチームは、シンプルに始めるのが最適です。 ただし、その特性により、プロジェクトがより複雑な GRA パターンを必要とする場合は、妥協しないでください。
各パターンに関連する一般的なプロジェクト特性：
-
GRA パターンなし：拡張する計画のないAdobe Commerceのシングルインスタンス。 Adobe Commerceの複数のインスタンスの共通性が最小限に抑えられています。
-
Git GRA パターンの分割：カスタマイズで Composer を避けたいチームは、ほとんどの場合、バルクパッケージパターンを Git の分割に推奨されるパターンです。
-
一括パッケージ GRA パターン：相互依存関係の高いカスタマイズコードベース。 インスタンスにはすべて、カスタムパッケージの非常に類似した組み合わせがあります。 個々のパッケージの頻繁な昇格や降格はありません。 コード管理の経験が少なく、シンプルさを必要とするチーム。
-
別個のパッケージ GRA パターン：柔軟なリリース範囲管理が必要です。 今後 5 年間で 50 個以下のカスタムパッケージが予想されます。 場合によっては、共通コードのグローバルレイヤーと地域レイヤー。 Monorepo パターンに移行する計画はありません。 チームは技術的に熟練しており、プロセスの厳密な遵守を行っています。
-
モノレポ GRA パターン：セパレートパッケージ GRA パターンのすべての特性。 今後 5 年間で 50 を超えるパッケージが予想されます。 広範な自動テストの必要性。 一時環境のサポート。 複雑なコードベースをエンタープライズ規模で拡張できます。メンテナンス・コストを同等の割合で拡張する必要はありません。
間違った選択のコスト
あるパターンから別のパターンへの移行が可能です。 下の図は、あるパターンから別のパターンに移動した場合の影響のレベルを示しています。 緑色の線は影響が小さく、黄色と黄色の線は複雑な移行に対して適度に複雑です。
