Arquitectura de software

Diseño para actualizaciones

Al ampliar los comportamientos de OOTB, es importante tener en cuenta las actualizaciones. Aplique siempre las personalizaciones en el directorio /apps y superponga los nodos correspondientes en el directorio /libs o utilice sling:resourceSuperType para ampliar el comportamiento predeterminado. AEM Aunque es posible que se necesiten algunas modificaciones para admitir una nueva versión de, la nueva versión no debe sobrescribir las personalizaciones si se sigue esta práctica.

Reutilizar plantillas y componentes siempre que sea posible

Esto permitirá que el sitio mantenga una apariencia más coherente y simplifique el mantenimiento del código. Cuando se necesite una plantilla nueva, asegúrese de ampliarla desde una plantilla base compartida para que los requisitos globales, como la inclusión clientlib, se puedan codificar en un solo lugar. Cuando se necesite un nuevo componente, busque oportunidades para ampliarse desde un componente existente.

Diseñar diseños de plantilla

Al definir qué componentes se pueden incluir en cada parsys de la página, se puede controlar la coherencia de la apariencia del sitio. Al restringir el acceso al diseño en las páginas, se puede permitir a los "superautores" modificar los componentes permitidos por página sin la intervención del desarrollador, siempre que los demás autores sigan los estándares corporativos.

Desarrollar una arquitectura sólida

SOLID es un acrónimo que describe cinco principios arquitectónicos a los que hay que adherirse:

  • S Principio de responsabilidad único: cada módulo, clase, método, etc., solo debe tener una responsabilidad.
  • O Principio abierto/Cerrado: los módulos deben estar abiertos para su extensión y cerrados para su modificación.
  • L Principio de sustitución de iskov: los tipos deben ser reemplazables por sus subtipos.
  • I Principio de segregación de interfaz: no se debe obligar a ningún cliente a depender de métodos que no utiliza.
  • D Principio de inversión de dependencia: los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambas deberían depender de abstracciones. Las abstracciones no deben depender de los detalles. Los detalles deben depender de las abstracciones.

La lucha por el cumplimiento de estos cinco principios debería dar como resultado un sistema que tenga una estricta separación de intereses.

SUGERENCIA

SOLID es un concepto comúnmente utilizado en la programación orientada a objetos y cada elemento es ampliamente discutido en la literatura de la industria.

Este es solo un breve resumen presentado para la concienciación y se le anima a que se familiarice con estos conceptos en más profundidad.

Siga el principio de solidez

El Principio de Solidez afirma que debemos ser conservadores en lo que enviamos, pero ser liberales en lo que aceptamos. En otras palabras, cuando enviamos mensajes a un tercero, debemos cumplir completamente con las especificaciones, pero cuando recibimos mensajes de un tercero, debemos aceptar mensajes no conformes siempre y cuando el significado del mensaje sea claro.

Implementar picos en sus propios módulos

Los picos y el código de prueba son parte integral de cualquier implementación de software de Agile, pero queremos asegurarnos de que no entren en nuestra base de código de producción sin el nivel adecuado de supervisión. Como resultado, se recomienda crear picos en su propio módulo.

Implementar scripts de migración de datos en su propio módulo

Los scripts de migración de datos, mientras que el código de producción, suelen ejecutarse solo una vez al inicio del sitio. Por lo tanto, tan pronto como el sitio está activo, esto se convierte en código muerto. Para garantizar que no se genere código de implementación que dependa de los scripts de migración, deben implementarse en su propio módulo. Esto también nos permite eliminar y retirar este código inmediatamente después del lanzamiento, eliminando el código muerto del sistema.

Seguir convenciones de Maven publicadas en archivos POM

Apache ha publicado convenciones de estilo en https://maven.apache.org/developers/conventions/code.html. Es mejor seguir estas convenciones, ya que hará que sea más fácil que los nuevos recursos se pongan al día rápidamente.

En esta página