Patron d'architecture
En informatique, un patron d'architecture est une solution générale et réutilisable à un problème d'architecture récurrent. Les patrons d'architecture sont semblables aux patrons de conception mais ont une portée plus large.  Ils servent de modèle de référence et de source d'inspiration lors de la conception de l'architecture d'un système ou d'un logiciel informatique, pour décomposer celui-ci en éléments plus simples.

Exemples de patron d'architecture

(travail atomique) 
Gère une liste d'objets durant une transaction et permet de gérer l'écriture des changements ainsi que les problèmes de concurrence.

(map d'identification) 
Charge en une seule fois tous les objets dans un map. Les objets sont ensuite retrouvés via la map. Ce pattern permet de créer un cache pour les objets dans la base de données.

(chargement fainéant) 
Crée un objet qui ne récupère pas toutes les données qui lui sont associées mais qui peut récupérer seulement celles dont il a besoin. Ce pattern est utile lorsqu'il faut faire des appels à une ou plusieurs base de données.

(champ d'identification) 
Sauvegarde l'identifiant d'un champ dans un objet afin de maintenir une unité entre l'objet contenu en mémoire et une ligne dans une base de données. Ce pattern est utile lorsqu'il y a un mapping entre les objets en mémoire et les lignes d'une base de données.

(mapping de clé externe) 
Map un objet avec une clé qui sert de référence entre différentes tables. Ce pattern peut être utilisé pour tous les cas où il n'y a qu'un seul champ qui sert d'identifiant entre les tables.

(mapping de tables associées) 
Sauve l'association de plusieurs lignes d'une table avec plusieurs lignes d'une autre table lorsque cette association est représentée dans la base de données par une troisième table. Ce pattern est très utile pour représenter une relation Many-to-many entre deux tables dans une base de données.

(mapping de dépendance) 
Crée une relation d'héritage dans les objets créés à partir de la base de données. Ce pattern est utile lorsqu'une table comporte plusieurs références vers d'autres tables mais que ces tables ne comportent pas de référence vers la première, on a donc un système de référence dans un sens qui est représenté dans ce pattern sous forme d'héritage.

(sérialisation de gros objets) 
Sauvegarde dans un gros objet par sérialisation à partir d'un champ d'une base de données un graphe d'objets. Ce pattern est très utile pour les données représentées en XML mais présente des faiblesses lorsqu'il faut utiliser du SQL car il ne permet pas de faire des requêtes SQL.

(héritage d'une table unique) 
L'ensemble des classes héritées sont enregistrées dans une seule table. Chaque ligne représente un objet. Une colonne supplémentaire contenant un détrompeur (souvent le nom de la classe fille) doit être ajoutée.

Forces 
 Une seule table à gérer dans la base de données
 Il n'y a pas de jointure à faire pour retrouver les données 
 Les changements dans la hiérarchie des champs n'affectent pas la base de données

Faiblesses 
 Les champs ne sont pas toujours fiables, ce qui peut poser problème lors de l'utilisation directe des tables.
 Les colonnes qui en sont utilisées que par quelques sous-classes participent au gâchis de la mémoire.
 Une seule table peut finir par devenir trop grosse ce qui diminuera les performances.
 Il n'y qu'un seul nom possible par champ car cela correspondra au nom de la classe.

(héritage d'une table par classe) 
Représente en une hiérarchie de classe héritée où chaque table représente une classe.

Forces 
 Toutes les colonnes sont fiables, faciles à comprendre et ne gâchent pas d'espace
 La relation entre la mémoire et la base de données est très simple

Faiblesses 
 Pour accéder à plusieurs tables, il est nécessaire de faire des jointures
 Tout changement dans les champs implique un refactoring de la base de données
 La classe mère risque de devenir un goulot d'étranglement à force d'être accédé en continu
 La normalisation peut rendre compliqué le pattern pour des requêtes ad-hoc.

Repository (répertoire) 
Crée un lien entre le domaine et la couche de donnée en utilisant une collection d'interface afin d'accéder aux objets du domaine. Ce pattern est utile lorsque la complexité du domaine est élevée. Cela permet d'isoler le domaine de la couche de données. Sur de gros systèmes avec beaucoup d'objets et de requêtes, cela réduit le code pour écrire toutes les requêtes. Cela permet de coder le reste de l'application sans penser aux requêtes pour accéder à la base de données.

Voir aussi

Articles connexes 
 Architecture logicielle
 Architecture en couches
 Entity-control-boundary
 Architecture hexagonale

Bibliographie 
 Martin Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley, 2013

Architecture informatique