Gran empresa Aplicación Java - Modularización

Question

Trabajo para una empresa en todo el país, por lo que el software que desarrollamos es a gran escala.

Nuestro sistema central está basado en la Web, que incluye webservices. Actualmente estamos rediseñando todo el proyecto y es momento de comenzar la estructura del proyecto.

Tenemos como 7 módulos web, incluido para el proyecto web basado en Struts2 y Spring 3.1. Un Webservice núcleo basado en JAX-WS y Spring 3.1

Mi pregunta es ¿cuáles son las mejores prácticas para el diseño de la estructura y la modularización de proyecto para un proyecto como este:

Vamos a utilizar definitivamente Maven y OSGi si es necesario. Estoy pensando en algo así como

WebProject.war 
    |---Web.xml 
    |--- Libs 
    | 
    |--- Web Module1.jar 
    |--- Web Module2.jar 
    |--- Web Module3.jar 
    |--- Web Module4.jar 
    |--- Web Module5.jar 
    |--- Web Module6.jar 

WebService.war 
    |---Web.xml 
    |--- Libs 
    | 
    |--- Service.jar 
    |--- Service2.jar 

EJBProject.jar 
    | 
    |--- module.jar 
    |--- module2.jar 

Esto es lo que yo personalmente tengo en mente, pero estamos buscando algo mejor modular para que podamos trabajar y desplegar WebModule1.jar sin afectar a los otros módulos y principal proyecto WebProject.war. También con esto queremos que los equipos especializados solo tengan el código de sus proyectos, por lo que si un equipo debe trabajar solo con Service2.jar en su IDE, solo tendrán el código Service2.jar y un proyecto de recursos con el otro proyecto ya compilado.

Gracias

Answer 1

El aspecto clave de la modularidad es que su módulo sabe tan poco como es humanamente posible para que pueda ser reutilizado en muchos contextos diferentes. Los errores solo ocurren cuando se viola una suposición, minimizar las suposiciones es el mayor asesino de errores. OSGi proporciona herramientas como μservicios que son muy buenos para permitir que las suposiciones permanezcan locales.

Su diseño se parece mucho a un proyecto web, lo cual es incorrecto ya que la mayoría del código que tenemos que desarrollar nosotros mismos debe ser independiente de la tecnología utilizada para presentarlo. Toda esta tecnología es probable que cambie en un futuro próximo, ya que las aplicaciones web se están desplazando rápidamente al navegador, los navegadores se están convirtiendo en clientes gordos otra vez. Es decir. las interfaces REST muy modernas ya se sienten anticuadas si ves lo que está haciendo la mensajería pura. Toda esta volatilidad significa que desea hacer sus módulos lo más desacoplados posible.

Así que nunca asociaría ningún código de dominio a nada que esté acoplado a bibliotecas que estén acopladas a la tecnología web. Estas dependencias transitivas te van a hacer daño en el futuro (cercano). Construyó pequeños módulos desacoplados cohesivos y los usó como bloques de lego para construir sus aplicaciones.

Answer 2

lo recomiendo mucho leer Kirk Knoernschild 's "Java Application Architecture: Modularity Patterns with Examples Using OSGi". Podría comenzar por modularizar la aplicación antes de migrar a OSGi (y definitivamente invertiría en una buena cobertura de prueba si aún no la tiene).

Si está utilizando la especificación de servlet 3.0, consulte el uso de fragmentos web.

En términos de la estructura que ha mostrado, yo diría que no anidan nada (excepto fragmentos web), los WAR pueden convertirse en WAB (paquete de aplicaciones web, básicamente un WAR flaco). Aproveche también los μServices de OSGi tanto como sea posible: ahí es donde comienza la diversión =)

Los frameworks OSGi de Enterprise como Karaf y Virgo ofrecen mucho soporte mientras se está sobre la división JEE-OSGi (Equinox y Felix solo son un poco a barebones).

Answer 3

Su estructura se ve bien para mí, que es la estructura típica para la mayoría de los proyectos, una recomendación que le daría es la versión de sus dependencias, por ejemplo, deje que su webproject.war dependa de webmodule1-1.3 decir, esto los proyectos finales potencialmente diferentes pueden tener diferentes versiones de tarros dependientes.

Uso experto definitivamente simplifican la gestión de estas dependencias

Si sus necesidades son para reemplazar dependencias en tiempo de ejecución, entonces sí, tendrá que ir a tecnologías como OSGi, sin embargo, si no se runtime modularización que busca , Recomendaría no comenzar con OSGi y mantener la pila más simple.

Answer 4

En función de los requisitos de su proyecto, como el desarrollo de módulos independientes y la actualización en tiempo de ejecución, Maven es la mejor solución.Proporciona un excelente soporte de dependencias y complementos y parece que todo lo que necesita para su proyecto ya está disponible:

• Spring/Struts/CXF/etc. artefactos de maven,
• WAR/JAR/etc. plugins,
• Servidores de aplicaciones implementan/prueban plugins, etc.
• Y solo puede proporcionar artefactos de maven comunes para equipos que desarrollan solo módulos específicos sin compartir toda la base de código.
• Maven es soportado por todos los servidores de integración continua (Hudson/TeamCity etc.)

OSGi. Si desea usarlo, debe observar cuidadosamente su diseño actual e intentar adaptarlo a μServices. En general, tendrá módulos con API, consumidores de API y proveedores de API. Te ayuda a dividir el desarrollo entre los equipos (por ejemplo, uno desarrolla un módulo de consumidor de API, otro - módulo de proveedor de API). Si lo necesita, puede dividir el módulo API consumidor/proveedor en 2+ paquetes OSGi (que son módulos Maven).

Answer 5

Después de lidiar con OSGi un poco y sentir algo de dolor, hemos desarrollado una modularidad sin osgos para Spring https://github.com/griddynamics/banshun ¡Ya está!