ソフトウェアのアーキテクチャ

アップグレードのためのデザイン

OOTB 動作を拡張するときは、アップグレードを念頭に置いておくことが重要です。カスタマイズは必ず /apps ディレクトリで適用し、/libs ディレクトリの対応するノードの上にオーバーレイするか、または sling: resourceSuperType を使用して初期設定済みの動作を拡張します。新しい AEM バージョンをサポートするためにいくつかの変更が必要になることがありますが、このプラクティスに従う場合は、新しいバージョンでその変更が上書きされないようにする必要があります。

可能な場合はテンプレートおよびコンポーネントを再利用する

これにより、サイトの外観と操作性をより一貫性のあるものにし、コードのメンテナンスを簡素化できます。新しいテンプレートが必要なときは、共有基本テンプレートから拡張してください。このようにすると、clientlib のインクルードといったグローバルな要件を 1 箇所でコーディングできます。新しいコンポーネントが必要な場合は、既存のコンポーネントからの拡張を検討してください。

テンプレートデザイン

ページで各 parsys にどのコンポーネントを含めることができるかを定義することで、サイトの外観と操作性における一貫性を制御できます。ページ上でのデザインへのアクセスを制限することにより、「スーパー作成者」は開発者の介入なしでページごとに許可されたコンポーネントを変更できるようになり、その一方で他の作成者が企業の標準を遵守するようになります。

SOLID アーキテクチャを開発する

SOLID は、アーキテクチャに関する準拠すべき 5 つの原則を示す略語です。

  • S（単一責任の原則）- 各モジュール、クラス、メソッドなどにはそれぞれ 1 つの責任だけを割り当てるようにします。
  • O（オープン／クローズドの原則 ）- モジュールは、拡張に対してはオープンにし、変更に対してはクローズドにします。
  • L（リスコフの置換原則） - タイプは、サブタイプに置き換え可能である必要があります。
  • I（インターフェイス分離の原則） - クライアントに対して、利用していないメソッドへの依存を強制しないようにします。
  • D（依存性逆転の原則） - 上位のモジュールは、下位のモジュールに依存しないようにします。どちらも、抽象に依存する必要があります。抽象が詳細に依存しないようにします。詳細が抽象に依存するようにします。

この 5 つの原則に準拠しようと努力することによって、システムでの厳密な関心の分離が実現します。

ヒント

SOLID はオブジェクト指向プログラミングで一般的に使用される概念で、各要素については業界文献で広く議論されています。

これは、わかりやすくするための短い要約です。これらの概念についてはさらに詳しく理解することをお勧めします。

堅牢性の原則に準拠する

堅牢性の原則では、送信内容に対しては保守的になり、受信内容に対しては寛容になることと規定しています。つまり、サードパーティにメッセージを送信するときには仕様に完全に準拠する必要がありますが、サードパーティからメッセージを受信するときには、仕様に準拠していないメッセージであっても、メッセージの意味が明白である限り、受け入れるようにします。

独自のモジュールにスパイクを実装する

スパイクおよびテストコードは Agile ソフトウェア実装の不可欠な要素ですが、それらが適切なレベルでの管理なしで実稼動コードベースに入り込まないようにする必要があります。結果として、独自のモジュールにスパイクを作成することをお勧めします。

独自のモジュールにデータ移行スクリプトを実装する

データ移行スクリプトは実稼動コードで、通常は、サイトの初期起動時に 1 回のみ実行されます。そのため、サイトが稼動中になるとすぐにデッドコードになります。データ移行スクリプトに依存する実装コードをビルドしないようにするには、データ移行スクリプトをそのモジュール自身に実装するようにします。こうすると、起動直後にこのコードを削除して廃棄できるので、システムからデッドコードが排除されます。

POM ファイルで公開済みの Maven 表記規則に従う

Apache が https://maven.apache.org/developers/conventions/code.html でスタイル規則を公開しています。新しいリソースを期待される水準にすることが容易になるので、この規則に従うことをお勧めします。

このページ