Arquitectura y paquetes

Question

En una arquitectura en capas, que tienen una capa de capa de presentación, capa de lógica y datos.

Hasta ahora, he estado agrupación clases en los paquetes de dominios, servicios y DAO. Esto representa el modelo con Entidades POJOs / APP, la capa de lógica de negocio y acceso a datos.

supongo que el dominio y los servicios podrían agruparse para formar la capa de lógica, sino que deja un signo de interrogación en la capa de presentación o interfaz de usuario. ¿Hay algunas convenciones, aunque no escrita, en términos de la agrupación de las clases en paquetes por su naturaleza en esta capa? O esto deja a la apreciación de quien está dirigiendo un proyecto?

Como una indicación adicional, estoy experimentando con aplicaciones web en el momento y con un paquete de "servlet" a los servlets de grupo y un paquete de "web" para ResponseHeaderFilters, ServletContextListeners y clases de utilidad. Me interesaría saber cómo se hacen las cosas con una aplicación de escritorio.

Answer 1

Nunca he oído hablar de las convenciones de nomenclatura de paquete en relación con la arquitectura. La única convención o 'mejores prácticas' que sé es que los nombres de los paquetes deben comenzar con un patrón único, lo más a menudo formado de un nombre de dominio inverso (como com.myCompany) o menos. Sólo para asegurarse de que no se agrega clases de diferentes bibliotecas para el mismo paquete (espacio de nombres), que podría dar lugar a efectos secundarios inesperados.

Pero de todos modos, que es la legibilidad aumenta si el nombre de los paquetes después de que el nivel o el uso. He visto un esquema como el follwing que en lo personal me gustó porque era fácil de encontrar e identificar las clases, y fácil de extender:

com
   .company
           .product
                   .module1
                           .server
                                  .function1
                                            .impl
                           .client
                                  .function1
                           .common
                                  .function1
                                            .impl

Answer 2

En realidad nunca he visto demasiado de un problema con esto.

Si nos fijamos en el diagrama de clases para su proyecto, verá casi instantáneamente agrupaciones lógicas, y la estructura de árbol de los paquetes tiende a asignar fácilmente a cualquier agrupación que necesita.

utilizando el sistema de nombres de dominio inverso (com.company.product ...) nunca encontrará una colisión incluso dentro de su propia empresa.

Usando el ejemplo de Andreas_D, bajo .server y .client puede que en realidad tiene un adicional de 3 o 4 niveles de paquetes con decenas o cientos de paquetes individuales dentro de él si su proyecto es lo suficientemente grande como para justificar que .. pero la estructura en ese nivel tiende a salir de su diseño de productos.

Nota: Este pregunta similar parece ser cada vez algunas buenas descripciones de cómo utilizar paquetes: