Arquitetura de software software-architecture
Design para atualizações design-for-upgrades
Ao estender os comportamentos do OOTB, é importante ter em mente as atualizações. Sempre aplique personalizações no diretório /apps e sobreponha os nós correspondentes no diretório /libs ou use sling:resourceSuperType para estender o comportamento pronto para uso. Embora algumas modificações possam ser necessárias para oferecer suporte a uma nova versão de AEM, a nova versão não deve substituir as personalizações caso essa prática seja seguida.
Reutilizar modelos e componentes sempre que possível reuse-template-and-components-when-possible
Isso permitirá que o site mantenha uma aparência mais consistente e simplifique a manutenção do código. Quando um novo modelo for necessário, certifique-se de estender de um modelo base compartilhado para que os requisitos globais, como a inclusão clientlib, possam ser codificados em um local. Quando um novo componente for necessário, procure oportunidades para se estender a partir de um componente existente.
Designs de modelo de design design-template-designs
Ao definir quais componentes podem ser incluídos em cada parsys na página, a consistência da aparência do site pode ser controlada. Ao restringir o acesso ao design nas páginas, os "superautores" podem ter permissão para modificar os componentes permitidos por página sem a intervenção do desenvolvedor, garantindo ao mesmo tempo que os outros autores sigam os padrões corporativos.
Desenvolver uma arquitetura SOLID develop-a-solid-architecture
O SOLID é um acrônimo que descreve cinco princípios arquitetônicos que devem ser respeitados:
- S Princípio de responsabilidade única - cada módulo, classe, método, etc. deve ter apenas uma responsabilidade.
- O Princípio aberto/fechado - os módulos devem ser abertos para extensão e fechados para modificação.
- L Princípio da substituição iskov - os tipos devem ser substituíveis pelos seus subtipos.
- I Princípio de segmentação da interface - nenhum cliente deve ser forçado a depender de métodos que não usa.
- D Princípio de inversão de dependência - Os módulos de alto nível não devem depender dos módulos de baixo nível. Ambos devem depender de abstrações. As abstrações não devem depender de detalhes. Os detalhes devem depender de abstrações.
O cumprimento destes cinco princípios deve conduzir a um sistema que tenha uma separação rigorosa das preocupações.
Siga o princípio da robustez follow-the-robustness-principle
O Princípio da Robustez afirma que devemos ser conservadores no que enviamos, mas ser liberais no que aceitamos. Em outras palavras, ao enviar mensagens para terceiros, devemos estar em conformidade total com as especificações, mas ao receber mensagens de terceiros, devemos aceitar mensagens não conformes, desde que o significado da mensagem seja claro.
Implementar picos em seus próprios módulos implement-spikes-in-their-own-modules
Picos e código de teste são parte integrante de qualquer implementação de software do Agile, mas queremos garantir que eles não entrem em nossa base de código de produção sem o nível apropriado de supervisão. Como resultado, é recomendável criar picos em seu próprio módulo.
Implementar scripts de migração de dados em seu próprio módulo implement-data-migration-scripts-in-their-own-module
Os scripts de migração de dados, enquanto o código de produção, geralmente são executados apenas uma vez na primeira inicialização de um site. Portanto, assim que o site estiver ativo, isso se torna código inativo. Para garantir que não criemos um código de implementação que dependa dos scripts de migração, eles devem ser implementados em seu próprio módulo. Isso também permite remover e desativar esse código imediatamente após o lançamento, eliminando o código inativo do sistema.
Siga as convenções Maven publicadas em arquivos POM follow-published-maven-conventions-in-pom-files
O Apache publicou convenções de estilo em https://maven.apache.org/developers/conventions/code.html. É preferível seguir estas convenções, uma vez que facilitará a rápida mobilização de novos recursos.