Esta es la respuesta más completa que te podemos brindar, pero primero mírala pausadamente y valora si se adapta a tu proyecto.
Solución:
Aquí hay un caso de la vida real.
Tengo un proyecto de varios módulos (y para su diatriba… no he visto ninguna complicación con él). El resultado final es una aplicación web, pero tengo diferentes módulos para api, impl y webapp.
12 meses después de crear el proyecto, descubro que tengo que integrarme con Amazon S3 mediante un proceso independiente que se ejecuta desde un contenedor. Agrego un nuevo módulo que depende de api/impl y escribo mi código para la integración en el nuevo módulo. Uso el complemento de ensamblaje (o algo parecido) para crear un jar ejecutable y ahora tengo una guerra que puedo implementar en Tomcat y un proceso que puedo implementar en otro servidor. No tengo clases web en mi proceso de integración de S3 y no tengo dependencias de Amazon en mi aplicación web, pero puedo compartir todas las cosas en api e impl.
3 meses después, decidimos crear una aplicación web REST. Queremos hacerlo como una aplicación separada en lugar de solo nuevas asignaciones de URL en la aplicación web existente. Simple. Un módulo más, otra aplicación web creada como resultado de la compilación experta sin retoques especiales. La lógica empresarial se comparte fácilmente entre webapp y rest-webapp y puedo implementarlos según sea necesario.
El principal beneficio de los módulos múltiples son
- un solo comando maven para construir todos sus módulos a la vez.
- y lo más importante: maven se encarga del orden de compilación por usted.
- configurar su servidor CI también es muy fácil: un solo trabajo de jenkins para construir todo.
Ya trabajé en un proyecto con unos 30 submódulos. A veces, necesita cambiar algo en más de un módulo, y es imprescindible ejecutar un solo comando y asegurarse de que todo lo que debe compilarse esté compilado en el orden correcto.
EDITAR
¿Por qué 30 submódulos?
Enorme marco con muchas características, muchos desarrolladores, separación de características en una base de módulo. Es un caso de uso de la vida real y la separación del código en módulos fue realmente significativa.
Creo que tiene razón en que la mayoría de los proyectos que usan módulos múltiples, en realidad no los necesitan.
En donde trabajo usamos proyectos multimódulo (y creo que por una buena razón). Tenemos algo similar a una arquitectura orientada a servicios, por lo que cada aplicación
- Un módulo de cliente
- Un módulo de interfaz (que tiene objetos compartidos entre el cliente y la implementación)
- un módulo de implementación
- un modulo de guerra
Estoy de acuerdo en que poner esa implementación y el módulo de guerra en el mismo módulo real estaría bien, pero el (posiblemente) beneficio de esto es que hay una división muy clara entre las clases que resuelven el problema y cómo la aplicación se comunica con el mundo exterior.
En proyectos anteriores que involucraban solo una aplicación web, traté de poner todo en el mismo módulo, ya que facilitaba las pruebas, dados los módulos que estaba usando.
Sección de Reseñas y Valoraciones
Si estás de acuerdo, tienes la opción de dejar una división acerca de qué te ha gustado de esta división.