소프트웨어 아키텍처 software-architecture

업그레이드 디자인 design-for-upgrades

OOTB 동작을 확장할 때 업그레이드를 염두에 두어야 합니다. /apps 디렉토리에 사용자 지정 사항을 항상 적용하고 /libs 디렉토리의 해당 노드 위에 오버레이하거나 sling:resourceSuperType을 사용하여 기본 동작을 확장합니다. 새 AEM 버전을 지원하기 위해 일부 수정 사항이 필요할 수 있지만, 이 방법이 따를 경우 새 버전이 사용자 지정을 덮어쓰지 않아야 합니다.

가능하면 템플릿 및 구성 요소를 재사용하십시오 reuse-template-and-components-when-possible

이렇게 하면 사이트에서 더 일관된 모양과 느낌을 유지하고 코드 유지 관리를 간소화할 수 있습니다. 새 템플릿이 필요한 경우 clientlib 포함 과 같은 글로벌 요구 사항을 한 위치에 코딩할 수 있도록 공유 기본 템플릿에서 확장해야 합니다. 새 구성 요소가 필요한 경우 기존 구성 요소에서 확장할 기회를 찾습니다.

템플릿 디자인 디자인 design-template-designs

페이지에서 각 parsys에 포함할 수 있는 구성 요소를 정의함으로써 사이트의 모양/느낌의 일관성을 제어할 수 있습니다. 페이지에서 디자인에 대한 액세스를 제한하여 "수퍼 작성자"가 다른 작성자가 회사 표준을 따르도록 하면서도 개발자 개입 없이 페이지당 허용되는 구성 요소를 수정할 수 있도록 할 수 있습니다.

솔리드 아키텍처 개발 develop-a-solid-architecture

SOLID는 다음과 같이 부착해야 하는 5가지 아키텍처 원칙을 설명하는 약어입니다.

5원칙을 지키고자 애쓰는 것은 근심분리 제도를 가지게 될 것이다.

견고성 원칙 준수 follow-the-robustness-principle

견고성 원칙은 우리가 보내는 것에 대해 보수적이어야 하지만 우리가 받아들이는 것에 대해 자유적이어야 한다는 것입니다. 즉, 제3자에게 메시지를 보낼 때는 규격에 완전히 부합해야 하지만 제3자로부터 메시지를 받을 때는 메시지의 의미가 분명하면 규정을 지키지 않는 메시지를 수락해야 합니다.

자체 모듈에서 스파이크 구현 implement-spikes-in-their-own-modules

스파이크와 테스트 코드는 모든 Agile 소프트웨어 구현의 필수적인 부분이지만, 적절한 수준의 감독 없이 프로덕션 코드 베이스에 들어가지 않도록 해야 합니다. 따라서 자체 모듈에서 스파이크를 만드는 것이 좋습니다.

자체 모듈에서 데이터 마이그레이션 스크립트 구현 implement-data-migration-scripts-in-their-own-module

데이터 마이그레이션 스크립트는 프로덕션 코드가 있는 동안 일반적으로 사이트를 처음 시작할 때 한 번만 실행됩니다. 따라서 사이트가 라이브되면 이것은 데드 코드가 됩니다. 마이그레이션 스크립트에 의존하는 구현 코드를 빌드하지 않도록 하려면 자체 모듈에서 구현해야 합니다. 또한 실행 직후 이 코드를 제거하고 사용 취소할 수 있으므로 시스템에서 데드 코드를 제거할 수 있습니다.

POM 파일에서 게시된 Maven 규칙 따르기 follow-published-maven-conventions-in-pom-files

Apache는에서 스타일 규칙을 게시했습니다. https://maven.apache.org/developers/conventions/code.html. 따라서 새 리소스를 신속하게 찾을 수 있게 되므로 이러한 규칙을 준수하는 것이 가장 좋습니다.