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

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

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

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

これにより、サイトの外観と操作性をより一貫性のあるものにし、コードのメンテナンスを簡素化できます。新しいテンプレートが必要な場合は、clientlibの組み込みなどのグローバル要件が1か所でコード化できるように、必ず共有ベーステンプレートからを拡張してください。 新しいコンポーネントが必要な場合は、既存のコンポーネントから拡張する機会を探します。

テンプレートデザイン

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

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

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

• ​​単一責任の原則 — 各モジュール、クラス、メソッドなどは1つの責任のみを持つべきです。
• ​​開封/閉鎖の原則 — モジュールは、拡張の場合は開き、変更の場合は閉じる必要があります。
• ​​Liskov Substitution Principle — 型は、サブタイプによって置き換え可能である必要があります。
• ​​インターフェイスの分離原則 — クライアントが使用しないメソッドに依存するよう強制されることはありません。
• ​​依存関係の反転の原則 — 高レベルのモジュールは、低レベルのモジュールに依存しないでください。どちらも、抽象に依存する必要があります。抽象が詳細に依存しないようにします。詳細が抽象に依存するようにします。

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

堅牢性の原則に準拠する

堅牢性の原則では、送信内容に対しては保守的になり、受信内容に対しては寛容になることと規定しています。つまり、第三者にメッセージを送る場合は、完全に仕様に準拠する必要がありますが、第三者からメッセージを受け取る場合は、メッセージの意味が明確である限り、不適合メッセージを受け取る必要があります。

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

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

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

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

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

Apacheはhttps://maven.apache.org/developers/conventions/code.htmlにスタイル規則を公開しています。 新しいリソースが迅速に現れるのを容易にするので、これらの規則に従うのが最善です。