Architettura del software

Progettazione per gli aggiornamenti

Quando si estendono i comportamenti OOTB, è importante tenere a mente gli aggiornamenti. Applicate sempre le personalizzazioni nella directory /apps e sovrapponete ai nodi corrispondenti nella directory /libs oppure utilizzate sling:resourceSuperType per estendere il comportamento out-of-the-box. Anche se possono essere necessarie alcune modifiche per supportare una nuova versione AEM, la nuova versione non deve sovrascrivere le personalizzazioni se questa procedura viene seguita.

Riutilizza modelli e componenti quando possibile

In questo modo il sito potrà mantenere un aspetto e un aspetto più coerenti e semplificare la manutenzione del codice. Quando è necessario un nuovo modello, accertatevi di estenderlo da un modello di base condiviso in modo che i requisiti globali, come l'inclusione clientlib, possano essere codificati in un'unica posizione. Quando è necessario un nuovo componente, cercate le opportunità di estendere da un componente esistente.

Progettazione di modelli

Definendo quali componenti possono essere inclusi in ogni parsys della pagina, è possibile controllare l'aspetto del sito. Limitando l'accesso alla progettazione sulle pagine, è possibile consentire agli "autori super" di modificare i componenti consentiti per pagina senza l'intervento dello sviluppatore, garantendo nel contempo che gli altri autori seguano gli standard aziendali.

Sviluppare un'architettura SOLID

SOLID è un acronimo che descrive cinque principi architettonici che devono essere rispettati:

• Principio di responsabilità unica: ogni modulo, classe, metodo, ecc. dovrebbe fare solo una cosa.
• Principio aperto/chiuso: i moduli devono essere aperti per l'estensione e chiusi per la modifica.
• Principio di sostituzione di Liskov - i tipi dovrebbero essere sostituiti dai loro sottotipi.
• Principio di segmentazione dell'interfaccia: nessun cliente deve essere costretto a dipendere da metodi che non utilizza.
• Principio di dipendenza: i moduli di alto livello non devono dipendere dai moduli di basso livello. Entrambi devono dipendere dalle astrazioni. Le astrazioni non devono dipendere dai dettagli. I dettagli devono dipendere dalle astrazioni.

Il rispetto di questi cinque principi dovrebbe tradursi in un sistema che preveda una netta separazione delle preoccupazioni.

Segui il principio di robustezza

Il principio della solidità afferma che dovremmo essere conservatori in ciò che inviamo, ma essere liberali in ciò che accettiamo. In altre parole, quando inviamo messaggi a terzi, dovremmo essere completamente conformi alle specifiche, ma quando riceviamo messaggi da terzi, dovremmo accettare messaggi non conformi fintanto che il significato del messaggio è chiaro.

Implementare i picchi nei propri moduli

Picchi e codice di test sono parte integrante di qualsiasi implementazione software Agile, ma vogliamo assicurarci che non entrino nella nostra base di codice di produzione senza il livello appropriato di sorveglianza. Di conseguenza, si consiglia di creare picchi nel proprio modulo.

Implementare gli script di migrazione dei dati nel proprio modulo

Gli script di migrazione dei dati, mentre il codice di produzione, vengono in genere eseguiti una sola volta all'avvio iniziale di un sito. Pertanto, non appena il sito è attivo, questo diventa codice morto. Per evitare che venga creato codice di implementazione che dipende dagli script di migrazione, questi devono essere implementati nel proprio modulo. Questo ci permette anche di rimuovere e ritirare questo codice subito dopo il lancio, eliminando il codice morto dal sistema.

Seguire le convenzioni pubblicate di Paradiso nei file POM

Apache ha pubblicato le convenzioni di stile all'indirizzo https://maven.apache.org/developers/conventions/code.html. E' meglio seguire queste convenzioni, in quanto renderà più facile reperire rapidamente nuove risorse.