JAVA - Normes pour les Noms de packages

Dans le développement d'une application, je préconise une orientation modulaire. Dans ce sens, je trouve que les packages peuvent bien séparer ou regrouper les modules.
La notion de modules est une notion assez floue. Dans certains cas, on utilisera la notion de projet pour séparer des modules. Cela s'avère vrai pour des gros modules, mais pour ma part je pense que la notion modulaire doit être présente dans tous les niveaux, c'est pour cela qu'un projet peut être vu comme une composition de différents modules, et un module lui-même est parfois peut aussi être décomposé en des modules plus petits...

Une architecture modulaire permet :

• de mieux séparer les concepts
• une meilleure abstraction
• une meilleure réutilisation
• une interchangeabilité
• facilite la maintenance du code

L'inconvénient majeur étant :

• une intégration plus difficile

On parle de couches horizontales dans une architecture n-tiers.
Un module peut être horizontal, vertical ou transversal.

Ci dessous vous trouverez une liste de noms de packages que j'utilise courament. Cette liste n'est biensur pas exhaustive, je liste ici seulement les noms qui peuvent être assez généraux et dont je trouve qu'il est bon de normer.

Ce package ne contient que des interfaces. On essayera de limiter ses liens avec le reste du système.

En Java, je trouve indispensable de gérer sa propre hiérarchie d'exceptions. Etant données que des abstractions peuevent utilisé des exceptions, je trouve d'autant plus interressant de séparer ces classes dans un package à part d'autant plus que des classes d'exception doivent rester très simples et ne pas avoir de dépendances importantes.

Ce que je considère comme le coeur de l'application: le modèle objet de données.
En général, une partie des objets métier peuvent être générés. On mettra alors les classes généré dans le package bo.generated.

Modules de traitement de données.
datamgr est le package racine de tous les modules non graphiques qui font du traitement de data.
Par exemples : convertisseur, parseur, logger, ...

GUI - Graphic User Interface - Modules d'interfaces graphiques.
gui est le package racine de tous les modules graphiques.
Afin de meiux séparer les modules graphiques, je trouve qu'il est tres adapté d'utiliser des interfaces pour les lier au reste du système.
Pour plus de détails MVC et XXXViewManager.

Il est toujours bon de séparer les classes générées des autres classes.
Par exemple pour les classes générés d'objets métiers, on utilisera bo.generated.

J'utilise de plus en plus des classes que j'appelle classes d'outils. Elles peuvents être vues comme des bibliothèques de fonctions. Cette technique peut, à première vu, paraitre rétrograde avec une orientation procédurale. En fait, elles s'intègrent parfaitement dans une méthodologie purement objet et permet une meilleure abstraction, simplifie les api, ...
En effet, dans beaucoup de cas ces classes travailleront sur des interfaces. Pour un exemple concrait, il suffit de regarder java.util.Collections.

En général je regroupe toutes les ressources graphiques d'un projet dans un package image.
Je regroupe les images génériques (icon windows, ...) dans 2 sous packages x16 et x32 en fonction de la dimension des images, respectivement 16x16 et 32x32.

images
  |- x16
  |- x32
  |- ...

Voici un exemple de structure:

com.myproject
  |- abstraction
  |- business
  |   |- generated
  |- datamgr
  |   |- ...

  |   |- ...

  |- exception
  |- gui
  |   |- ...

  |   |- ...

  |- images
  |   |- x16
  |   |- x32
  |   |- ...

  |- tools
  |   |- comparator