Cela n'est probablement pas nouveau. C'est quelque chose qui vous a certainement déjà été enseigné à l'école ou à l'université.
Lorsque des développeurs parlent le même langage, partagent la même vision de la structure d'un système, ils sont plus efficaces. Bien qu'il soit possible de découper un système de nombreuses façons, la représentation qui suit a le mérite d'être très générale et de faire l'unanimité parmis les développeurs. Elle a déjà été appliquée dans de très nombreux projets et sera familière aux développeurs séniors. Même si les techniques de conception les plus récentes suggèrent une génération spontanée d'un framework, une différentiation et une abstraction qui se créent naturellement, avoir cette représentation en tête et certains automatismes dans les dépendances qui y sont liés est un gage d'aller dans la bonne direction.
En effet, n'importe quelle application informatique peut être décrite et découpée selon la représentation suivante:
|
Frontière Présentation IHM
|
Controleur
|
Métier Domaine |
Persistance
|
Database
|
regroupe toutes les classes et fonctions qui s'occupent de gérer l'affichage et les entrées.
regroupe les classes, fonctions et procédures qui détiennent la logique des cas d'utilisation. Elles vont manipuler des classes métier et vont fournir des données à la frontière.
regroupe les classes, fonctions et procédures qui gèrent les objets liés aux spécificités du client. Sont sollicitées par le controleur et manipulent les données issues de la base (chargement, sauvegarde, tri, collections)
regroupe les classes, fonctions et procédures qui savent comment accéder aux données. Connection à la base de données, lecture de fichiers xml...
le système de base de données lui-même, contenant parfois des parties du projet (triggers, procédures stockées)