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

最終更新日: 2023-12-07

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

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

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

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

テンプレートデザイン

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

SOLID アーキテクチャを開発

SOLID は、従うべき 5 つのアーキテクチャ原則を表す頭字語です。

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

この 5 つの原則に遵守に努めることで、懸念事項が厳密に分離されたシステムが確立できるはずです。

ヒント

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

この情報は、あくまでも理解のために提示された簡単な要約であり、これらの概念についてはさらに詳しく学ぶことをお勧めします。

堅牢性の原則に準拠する

堅牢性原則では、送信するものに関しては厳密に、受信するものに関しては寛容になることと規定しています。つまり、サードパーティにメッセージを送信する際には、仕様に完全に準拠する必要があります。ただし、サードパーティからメッセージを受け取る際には、メッセージの意味が明確である限り、不適合なメッセージも受け入れる必要があります。

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

スパイクとテストコードは、アジャイルソフトウェアの実装の一部です。ただし、適切な管理レベルがない限り、実稼動環境のコードベースに侵入しないようにする必要があります。その結果、独自のモジュールでスパイクを作成することをお勧めします。

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

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

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

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

このページ