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

アップグレード用のデザイン design-for-upgrades

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

可能な場合はテンプレートおよびコンポーネントを再利用する reuse-template-and-components-when-possible

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

テンプレートデザイン design-template-designs

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

SOLID アーキテクチャの開発 develop-a-solid-architecture

SOLID は、次の 5 つのアーキテクチャ原則に従う必要があることを表す頭字語です。

この 5 つの原則に従うよう努力すれば、厳密に懸念を分離できるシステムになるはずです。

堅牢性の原則に準拠する follow-the-robustness-principle

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

独自のモジュールにスパイクを実装する implement-spikes-in-their-own-modules

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

独自のモジュールにデータ移行スクリプトを実装する implement-data-migration-scripts-in-their-own-module

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

POM ファイルで公開済みの Maven 表記規則に従う follow-published-maven-conventions-in-pom-files

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