Wiki - 1 output

Exemple pris en référence

Le présent article apporte des précisions quand au nommage orienté métier : la documentation de base sur la classe de lien explique le principe sans tenir compte de l’espace de nommage, ici nous verrons concrètement comment nommer votre trait et vos classes de lien dans le cas le plus complet.

Prenez connaissance de l’exemple dans l’article classe de lien. Pour résumé nous avions :

• deux classes métier Order et Salesman
• un trait pour la partie commune des classes de lien Order_Salesman_Trait
• deux classes de lien Order_Salesman extends Salesman et Salesman_Order extends Order

Les noms utilisés pour ces classes dans l’exemple partent du principe qu’elles sont toutes dans le même espace de nommage, qui ne contiendrait aucune référence ni à Order ni Salesman. Si c’était le cas, il faudrait pour respecter les conventions de nommage éviter les répétitions.

Par exemple My\Application\Order\Order_Salesman ne respecterait pas cette convention.

Séparation métier et choix de l’emplacement de la fonctionnalité “lien entre commercial et commande”

Dans une architecture métier des dossiers et espaces de nommage, il faut choisir avec soin l’endroit où on stockera notre fonctionnalité.

Un lien entre deux classes constitue en terme de fonctionnalité un “pont” entre deux fonctionnalités : ainsi il va falloir choisir de stocker la fonctionnalité “lien entre commercial et commande”, soit sous la fonctionnalité commande, soit sous la fonctionnalité commercial, soit même en dehors. En fonction des cas métiers, on choisira l’un ou l’autre.

Dans le cas présent, le lien entre commerciaux et commandes a de l’intérêt principalement d’un point de vue commande. Le plus clair en terme d’organisation fonctionnelle est de le considérer comme cela.

L’arborescence des classes sera donc :