Architecture et paquets

Question

Dans une architecture en couches, vous avez une couche de présentation, couche de couche logique et des données.

Jusqu'à présent, j'ai regrouper les classes en domaine, les packages de services et dao. Cela représente le modèle avec les entités POJO / JPA, la couche logique métier et l'accès aux données.

Je suppose que le domaine et les services pourraient être regroupés pour former la couche logique, mais qui laisse un point d'interrogation sur la couche de présentation ou l'interface utilisateur. Y a-t-il des conventions, même non écrite, en termes de regrouper les classes en paquets par leur nature dans cette couche? Ou est-ce laissée à l'appréciation de celui qui dirige un projet?

A titre indicatif supplémentaire, j'expérimente avec des applications web au moment et en utilisant un package "servlet" pour groupe servlets et un paquet "web" pour ResponseHeaderFilters, ServletContextListeners et les classes utilitaires. Je serais curieux de savoir comment les choses sont faites avec une application de bureau.

Answer 1

Je ne l'ai jamais entendu parler de conventions de nommage des paquets en ce qui concerne l'architecture. La seule convention ou les « meilleures pratiques » Je sais est que vos noms de paquets doivent commencer par un modèle unique, le plus souvent formé d'un nom de domaine inversé (comme com.mycompany) ou plus. Juste pour vous assurer que vous ne pas ajouter des classes de différentes bibliothèques au même package (espace) qui pourrait conduire à des effets secondaires inattendus.

Mais de toute façon, il est augmente la lisibilité si vous nommez les paquets après le niveau ou l'utilisation. Je l'ai vu un régime comme le follwing qui me plaisait personnellement parce qu'il était facile de trouver et identifier les classes, et facile à étendre:

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

Answer 2

Je ne l'ai jamais vraiment vu trop d'un problème avec cela.

Si vous regardez le diagramme de classes pour votre projet, vous aurez presque instantanément voir des regroupements logiques, et la structure arborescente des paquets tend à la carte facilement à tout vous groupant besoin.

en utilisant le système inverse de nom de domaine (com.company.product ...) vous ne trouverez jamais une collision même dans votre propre entreprise.

En utilisant l'exemple de Andreas_D, sous .server et .client vous pouvez effectivement avoir un 3 ou 4 niveaux supplémentaires de paquets avec des dizaines ou des centaines de paquets individuels à l'intérieur si votre projet est assez grand pour justifier que .. mais la structure à ce niveau a tendance à sortir de la conception de votre produit.

Note: Cette question similaire semble obtenir quelques bonnes descriptions comment utiliser les paquets: