DDD (Domain-Driven Design)

SOLID

Principe de conception

Architecture

Références

L'actualité

Parcours & Expérience





Librairie

L'information

DDD > Architecture > N-Tiers Architectures

L'architecture trois tiers, aussi appelée architecture à trois niveaux ou architecture à trois couches, est l'application du modèle plus général qu'est le multi-tier.

L'architecture logique du système est divisée en trois niveaux ou couches :
  • couche de présentations
  • couche de traitement
  • couche d'accès aux données
C'est une architecture basée sur l'environnement client-serveur.
  

Son nom provient de l'anglais tier signifiant étage ou niveau. Il s'agit d'un modèle logique d'architecture applicative qui vise à modéliser une application comme un empilement de trois couches logicielles (ou niveaux, étages, tiers) dont le rôle est clairement défini :

  • la présentation des données, correspondant à l'affichage, la restitution sur le poste de travail, le dialogue avec l'utilisateur
  • le traitement métier des données, correspondant à la mise en oeuvre de l'ensemble des règles de gestion et de la logique applicative
  • l'accès aux données persistantes : correspondant aux données qui sont destinées à être conservées sur la durée, voire de mani ère définitive

DDD > Architecture > Hexagonal Architecture

WorkingProcess...
Lorem ipsum dolor sit amet, vel mauris interdum.
Sed wisi nibh aptent ante, vestibulum velit rhoncus sed porta arcu aptent. Consectetuer vel, ipsum nec. Perspiciatis sit tempor, diam id sapien orci amet. Nunc dolor sed feugiat magna ut. Ad et nec at lacus, nibh turpis nonummy lectus neque lacinia platea, pulvinar anim eget felis, praesent semper. Et pellentesque. Elementum integer cursus vestibulum, diam velit dis, nulla lorem facilisi ut mauris. Elit et urna. Pharetra pellentesque velit, adipiscing ultrices in massa ultricies, et libero donec a ut mattis molestie. Adipiscing maecenas congue maecenas odio augue posuere, interdum eget nulla elit, eros orci turpis amet ut aliquam, dolor ut ut ac.



  

DDD > Architecture > Onion Architecture

Les applications conçues selon le principe d'inversion des dépendances et les principes DDD (conception pilotée par le domaine) présentent au final plus ou moins la même architecture. Les noms donnés à cette architecture ont beaucoup varié au fil des années. Au début, on l'a nommée architecture hexagonale, puis architecture ports-adaptateurs. Plus récemment, on l'a appelée architecture en oignon ou architecture propre.

L'architecture propre met la logique métier et le modèle d'application au centre même de l'application. Au lieu que la logique métier dépende des préoccupations de l'accès aux données ou d'une autre infrastructure, cette dépendance est inversée : les détails de l'infrastructure et de l'implémentation dépendent du noyau de l'application. Cela s'obtient par la définition d'abstractions, ou interfaces, dans la couche Noyau de l'application, lesquels sont ensuite implémentés par les types définis dans la couche Infrastructure. Cette architecture est souvent représentée sous la forme d'une série de cercles concentriques, à l'image des couches d'un oignon. La figure 5-7 montre un exemple de ce style de représentation architecturale.



Dans ce diagramme, le flux des dépendances va du cercle extérieur vers le cercle le plus intérieur. La couche Noyau de l'application tire son nom de sa position au coeur de ce diagramme. Par ailleurs, comme vous pouvez constater sur le diagramme, la couche Noyau de l'application n'a aucune dépendance vis-à-vis des autres couches de l'application. Les entités et les interfaces de l'application se trouvent au centre même du diagramme. Juste après vers l'extérieur, mais toujours dans la couche Noyau de l'application, viennent les services de domaine, qui implémentent généralement les interfaces définies dans le cercle central. À l'extérieur de la couche Noyau de l'application, les couches Interface utilisateur et Infrastructure dépendent toutes deux de la couche Noyau de l'application, mais elles ne dépendent pas (nécessairement) l'une de l'autre.

  

DDD > Architecture > SOA (Service Oriented Architecture)

Une architecture orientée service se conforme à divers principes de gestion des services influençant directement le comportement intrinsèque d'une solution logicielle et le style de sa conception :

  • L'encapsulation des services.
  • Le faible couplage des services avec la maintenance d'une relation réduisant les dépendances.
  • Le contrat de service adhère à un accord de communication, collectivement défini avec un ou plusieurs documents de description.
  • L'abstraction des services dissimulant la logique du service à l'extérieur.
  • La réutilisation des services partageant la logique entre plusieurs services avec l'intention de promouvoir la réutilisation.
  • La composition des services.
  • L'autonomie des services.
  • L'optimisation des services.
  • La découverte des services depuis leur description extérieure.
  • L'architecture orientée service représente un moyen technique d'intégration des divers systèmes d'information de l'entreprise considérant chaque ressource informatique comme un service. Elle permet de construire les buildings blocks qui composeront l'urbanisme du système d'information.
La notion d'interface est importante dans l'approche orientée service. En effet, elle représente le point d'entrée unique vers les fonctionnalités de la solution logicielle et assure la communication grâce à l'échange de messages. Chaque message est porteur de la sémantique particulière à la solution logicielle. De plus ce message est rédigé dans un langage compréhensible aux deux parties en présence. Les services proposés d'une architecture agile décrivent la structure des messages qu'ils attendent du client.

L'architecture orientée service est une solution logicielle distribuée. Elle propose un mécanisme d'échange de messages sécurisé entre les systèmes d'informations sous-jacents en employant des protocoles de communication standardisés. Cette approche offre à l'architecture une opportunité d'ouverture sur un large éventail de solutions logicielles existantes.