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

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

標準動作を拡張する場合は、アップグレードを念頭に置いておくことが重要です。 カスタマイズは必ず /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

スパイクとテストコードは、アジャイルソフトウェアの実装の一部です。ただし、これらのユーザーが、適切なレベルでの管理を行わずに実稼動コードベースに移動しないようにしたいと考えています。 その結果、独自のモジュールでスパイクを作成することをお勧めします。

独自のモジュールにデータ移行スクリプトを実装 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 でスタイル規則を公開しています。新しいリソースを期待される水準にすることが容易になるので、この規則に従うことをお勧めします。