Architecture DDDD N-Layered (Distributed Domain Driven Design) et .NET

Régulièrement, l'équipe des architectes Microsoft met à jour un excellent document d'architecture pour les très gros projets. Cet article a pour but de présenter en synthèse cette architecture, particulièrement bien découpée.

Besoins en architecture

Il existe une grosse demande pour faire correspondre les patterns d’architectures avec les toutes dernières technologies Microsoft.
Il est nécessaire de bénéficier d’architectures d’entreprise préétablies pour avoir une démarche unifiée de construction des applications.

Les frameworks techniques

Les briques technologiques offertes par Microsoft (ou le monde du .NET) sont extrêmement nombreuses: Framework .NET, Silverlight, WPF, WCF, WF, ASP.NET MVC, Windows Identity Foundation, Entity Framework, Azure, SQL Server, Unity, …
Comment distribuer tous ces frameworks sur une architecture d’entreprise ?

Objectifs de l'architecture DDDD .NET

  • Montrer les dernières tendances et patterns pour les applications d’entreprise.
  • Lier ces derniers aux technologies.
  • Fournir un moyen de standardiser les développements.
  • Améliorer l’adoption du .NET dans les scénarios d’entreprise complexes.

Types d'applications visées

  • Des applications d’entreprise complexes.
  • Beaucoup de logique et de règles métier.
  • Besoins de qualité de service (Sécurité, Performance et scalabilité, Tests unitaires, Longue vie logicielle)

Les tendances de l’architecture DDDD

  • Isolation de la couche du domaine (concepts d’inversion de contrôle et d’injection de dépendances).
  • Découpler toutes les couches d’infrastructure de la couche du domaine.
  • Utilisation de nombreux patterns d’architecture (MVVM, MVC, MVP, …).
  • Utilisation d’ORM.

Vue macroscopique (notez le sens des dépendances)

Synthèse Distributed Domain Driven Design

Vue détaillée

Détail Distributed Domain Driven Design

Distribution des frameworks sur l'architecture

Distribution des frameworks

  • WPF, Windows Presentation Foundation: l'approche client lourd vectorielle (XAML).
  • SilverLight: l'approche client riche vectorielle (XAML). Notez que Microsoft oriente plutôt SilverLight vers les plateformes mobiles comme Windows Phone 7 (Strategy Shift).
  • ASP.NET MVC: Le framework pour les applications Web utilisant le pattern Modèle, Vue, Contrôleur.
  • WCF, Windows Communication Foundation: pour l'unification des technologies distribuées (Remoting, WebServices, MSMQ, ...).
  • WF, Workflow Foundation: La brique workflow (utilisée par exemple dans SharePoint).
  • ADO.NET Entity Framework: l'ORM de microsoft.

Note: cette architecture est compatible 'Cloud', il est donc possible de positionner au besoin certaines couches sur Azure, la plateforme dédiée Microsoft.

La couche du domaine

  • C’est le cœur du logiciel (base de discussion avec un expert métier)
  • Contient tous les concepts métier « purs » et les entités associées.
  • Elle ne doit pas être contaminée avec des problématiques issues d’autres couches.
  • Elle doit être indépendante de toute source de données ou technologie d’accès.
  • Toutes les dépendances doivent utiliser des abstractions ou des interfaces.
  • On utilise des conteneurs IoC (comme Unity) pour proposer des implémentations interchangeables (IoC/DI).
  • Les entités (au sens ORM) sont présentes dans cette couche.

La couche d'accès aux données

  • L’utilisation d’un ORM permet d’implémenter plus facilement les concepts de Repository et d’Unit Of Work.
  • On utilise Entity Framework et des templates T4 permettent de générer les entités dans la couche du domaine.
  • Ces entités sont du type STE (Selft Tracking Entity) pour les exigences SOA du DDDD.

La couche application

  • Contient toute la plomberie de coordination.
  • C’est typiquement une couche technique contenant des adaptateurs, des workflows (WF).
  • En particulier elle contient et implémente tous les services applicatifs.

La couche de services distribués

  • Cette couche est normalement très fine.
  • Elle ne sert qu’à des fins de publication.
  • L’implémentation véritable se situe au niveau de la couche application.
  • On utilise typiquement WCF pour cette couche

La couche de présentation

  • On utilise les patterns adaptés:
  • MVC pour les clients légers (ASP.NET MVC)
  • MVP pour les clients lourds (WinForms)
  • MVVM pour les clients riches (SilverLight) ou lourds (WPF)

La couche cross-cutting

  • Elle contient toutes les problématiques transverses et liées à la QoS.
  • Sécurité
  • Cache
  • Gestion des exceptions
  • Validations (non métier)
  • Monitoring
  • Internationalisation

Synthèse

  • Dans l’approche DDDD, tout doit tourner autour du domaine.
  • Des mécanismes d’abstractions avec les autres couches permettent à la couche du domaine de ne jamais à avoir à gérer la persistance des données ou les tâches applicatives ou techniques.
  • La couche du domaine se concentre essentiellement sur le métier.
  • Les couches ainsi isolées sont plus facile à maintenir car elles peuvent évoluer à des rythmes différents : la couche d’accès aux données va évoluer au fil des technologies alors que la couche du domaine va évoluer uniquement quand la logique du métier l’exigera.
  • La notion de « cross-cutting code » est une notion suivant laquelle tout le code horizontal (gestion de la sécurité, du code, instrumentation) doit être séparé des couches fondamentales.

3 commentaires

  1. Intéressant.
    Merci pour cette introduction au DDDD. Aurais-tu la possibilité de situer les différées briques MS que tu cites, sur ton diagramme?
    Merci.