Tener un poco de debate sobre la estructura inicial del proyecto (usando Maven / Eclipse) para una gran aplicación Java.
Opción 1:
entities (i.e. the whole database using Hibernate classes-first)
services (i.e. sets of read/write operations on the entities)
app (perhaps split up more further down the line)Opcion 2:
area1-entities
area1-services
area1-app
area2-entities
area2-services
area2-app
...
(where area1, area2 etc. are functional areas of the system)La opción 2 claramente dará como resultado muchos más proyectos / módulos de Maven y significa que las clases que generarían la base de datos se distribuyen entre múltiples proyectos. ¿Alguien podría aconsejar pros / contras de cada enfoque?
Respuestas:
Sugeriría no hacer nada.
Intentar imponer una estratificación técnica con una estructura de paquete genera muchos enredos en su aplicación. Sin mencionar el hecho de que nos esforzamos por ocultar todo detrás de una interfaz de servicio y lo primero que hacemos (principalmente debido al empaque) es hacer que todo sea una
public class. Esto se convierte en doloroso cuando hay una separación entre un técnicox.y.z.servicey elx.y.z.repositorypaquete, ahora todo puede acceder al repositorio. Boom allí va su encapsulación dentro de la capa de servicio.En su lugar, debe seguir un enfoque más funcional y basado en la cebolla ( arquitectura limpia , arquitectura hexagonal ). Esto también está muy en línea con el Principio de responsabilidad única (cuando se aplica a un paquete) y también de acuerdo con los principios de empaque
Oliver Gierke ha escrito una buena publicación sobre componentes de empaque juntos en Java. Simon Brown ha escrito una historia más general sobre el tema.
Me esforzaría por una estructura de paquete central como la siguiente para mantener el núcleo de su aplicación:
Ahora, si tiene una interfaz web, agregue, por ejemplo, un
websubpaquete, para que un servicio webwso unrestpaquete contengan solo eso. Básicamente se conecta al núcleo.Ahora podría considerar reutilizar los objetos del interior de su núcleo en las otras capas, pero en mi humilde opinión, es mejor usar un dominio específico para esa capa. Como, al igual que con el mapeo de objetos a SQL, (a menudo) hay una falta de coincidencia en lo que queremos mostrar en la pantalla o usar como XML en el servicio web y cómo se implementa la lógica de negocios. Dependiendo de la complejidad del negocio y los dominios web, podría considerarlos como dominios de problemas separados para resolver los que necesitan estar conectados, básicamente 2 contextos limitados diferentes .
Para usar una cotización de un recurso CQRS
No intente poner todo en un solo modelo (dominio), separe las responsabilidades. Probablemente termines con más clases (más pequeñas) pero una separación más limpia entre las capas de tu aplicación.
Nota final
Recuerde que crear una arquitectura es decidir las compensaciones de una solución a la otra. Depende en gran medida de la complejidad del dominio y se debe principalmente a los requisitos funcionales de su aplicación. Sin embargo, está influenciado por las restricciones no funcionales (rendimiento, seguridad) y ambientales (lenguaje de uso, plataforma, experiencia). Y la arquitectura, como la codificación, nunca se termina, cada nuevo requisito puede (y tal vez debería) conducir a un rediseño de la aplicación.
Descargo de responsabilidad
Sí, también intenté poner todo en un solo modelo, y sí, también intenté usar una separación técnica en mis aplicaciones. Sin embargo, después de un par de años de experiencia en la creación de capas de aplicaciones enredadas (al principio parece una buena idea, luego la aplicación comienza a crecer ...) pensé que debía haber otra forma.
Enlaces
Libros
fuente