Instructions: Structure en couches
Ces instructions présentent des stratégies de division d'un système en couches.
Relations
Eléments connexes
Description principale

Instructions relatives aux couches

Les couches offrent une division logique de sous-systèmes en un certain nombre d'ensembles, avec certaines règles concernant la formation de relations entre les couches. Les couches offrent un moyen de restreindre les dépendances entre les sous-systèmes, et permettent par conséquent que le système soit mieux associé et donc plus facilement entretenu.

Les critères de regroupement des sous-systèmes suivent quelques schémas :

  • Visibilité. Les sous-systèmes peuvent dépendre uniquement de sous-systèmes de la même couche et de la couche inférieure suivante.
  • Volatilité.
    • Dans les couches supérieures, mettez des éléments qui varient en fonction des exigences de l'utilisateur.
    • Dans les couches inférieures, mettez des éléments qui varient en fonction de la plate-forme de mise en place (matériel, langue, système d'exploitation, base de données, etc) .
    • Au milieu, mettez des éléments qui s'appliquent en général à une large gamme de systèmes et d'environnements de mise en place.
    • Ajoutez des couches lorsque des divisions supplémentaires dans ces grandes catégories aident à organiser le modèle.
  • Généralité. Les éléments de modèle abstrait tendent à être placés plus bas dans le modèle. S'ils ne sont pas spécifiques à la mise en place, ils ont tendance à graviter vers les couches du milieu.
  • Nombre de couches. Pour un petit système, trois couches suffisent. Pour un système plus complexe, 5 à 7 couches sont généralement suffisantes. Quel que soit le degré de complexité, il convient d'être méfiant dès que le nombre de couches est supérieur à dix (votre méfiance devant augmenter avec le nombre de couches). Certaines règles générales sont présentées ci-dessous :

Nombre de classes

Nombre de couches

0 - 10

Aucune couche nécessaire

10 - 50

2 couches

25 - 150

3 couches

100 - 1000

4 couches

Les sous-systèmes et les packages d'une couche donnée doivent uniquement dépendre de sous-systèmes de la même couche et de la couche inférieure. Le non-respect des restrictions de dépendance entraîne une dégradation architecturale et rend le système fragile et difficile à maintenir.

Les exceptions comprennent les cas où des sous-systèmes ont besoin d'un accès direct aux services des couches inférieures : une décision consciente doit être prise sur la façon de gérer les services primitifs nécessaires dans le système tels que l'impression, l'envoi de messages, etc. Il y a peu d'intérêt à restreindre les messages aux couches inférieures si la solution est de mettre en place de façon efficace les passages d'appels dans les couches intermédiaires.

Division en patterns

Dans les couches supérieures du système, des divisions supplémentaires peuvent aider à organiser le modèle. Les instructions suivantes de division présentent différentes questions à considérer :

  • Organisation d'utilisateurs. Les sous-systèmes peuvent être organisés en lignes qui reflètent l'organisation des fonctions dans l'organisation de l'activité (par ex., une division se produit selon des lignes de services). Cette division se produit souvent au début de la conception, car un modèle d'entreprise existant a une structure fortement divisée organisationnellement. Ce schéma d'organisation affecte en général uniquement les quelques couches supérieures des services spécifiques aux applications et disparaît souvent au fil de l'évolution de la conception.
    • La division en lignes d'organisation d'utilisateurs peut souvent être un bon point de départ pour le modèle.
    • La structure de l'organisation d'utilisateurs n'est pas stable sur une longue période (en raison de la réorganisation de l'activité) et n'est pas une bonne base à long terme pour une division du système. L'organisation interne du système doit permettre à celui-ci d'évoluer et d'être maintenu indépendamment de l'organisation de l'activité qu'il prend en charge.
  • Domaines de compétences et/ou aptitudes. Les sous-systèmes peuvent être organisés pour diviser les responsabilités pour certaines parties du modèle parmi différents groupes dans l'organisation de développement. En général, ceci se produit dans les couches inférieures et du milieu du système, et reflète le besoin de spécialisation en compétences lors du développement et de la prise en charge d'une technologie infrastructurelle complexe. Exemples de telles technologies : la gestion de réseaux et de la distribution, la gestion de bases de données, la gestion des communications et le contrôle des processus, entre autres. La division en lignes de compétences peut aussi se produire dans les couches supérieures, où une compétence particulière dans le domaine des problèmes est nécessaire pour comprendre et prendre en charge les fonctions métier clés ; par exemple, la gestion des appels de télécommunication, le commerce de titres de placement, le traitement des demandes d'indemnisation et le contrôle du trafic aérien, pour n'en citer que quelques uns.
  • Distribution du système. Dans n'importe quelle couche du système, les couches peuvent être encore divisées "horizontalement" pour refléter la distribution physique des fonctions.
    • La division pour refléter la distribution peut aider à visualiser les communications du réseau qui se produiront lors de l'exécution du système.
    • La division pour refléter la distribution peut cependant rendre le système plus difficile à modifier si le modèle de déploiement change de façon significative.
  • Domaines de discrétion. Certaines applications, en particulier celles qui nécessitent une autorisation de sécurité spéciale pour développer et/ou prendre en charge, requièrent une division supplémentaire en lignes de privilèges d'accès de sécurité. Le logiciel qui contrôle l'accès aux domaines de discrétion doit être développé et maintenu par du personnel autorisé. Si le nombre de personnes qui ont de l'expérience sur le projet est limité, la fonction qui requiert une autorisation spéciale doit être divisée en sous-systèmes qui seront développés indépendamment d'autres sous-systèmes, les interfaces vers les domaines de discrétion constituant l'unique aspect visible de ces sous-systèmes.
  • Domaines de variabilité. Les fonctions susceptibles d'être facultatives, et donc fournies uniquement dans certaines variantes du système, doivent être organisées en sous-systèmes indépendants qui sont développés et fournis indépendamment des fonctions obligatoires du système.