La conception pilotée par le domaine (Domain-Driven Design, ou DDD) est une approche de conception que a pour principe que la conception est basée sur le modèle et que l'accent doit être sur le domaine et la logique associée ¹⁾.

On doit, entre autre :

• Interagir avec les experts du domaine
• Modéliser un seul sous-domaine à la fois

Les avantages :

• Flexible parce qu'on a des pièces quasi-atomiques du domaine
• Association plus facile avec la vision du client et la perspective du problème
• Résulte en un code bien organisé et facilement testable
• La logique d'affaire réside en un seul endroit

While Domain-Driven Design provides many technical benefits, such as maintainability, it should be applied only to complex domains where the model and the linguistic process provide clear benefits in the communication of complex information, and in the formulation of common understanding of the domain.

– Eric Evens, Domain-Driven Design

Les désavantages

• Beaucoup de temps passé à discuter de ce qui fait partie du domaine ou non et en communication avec les experts du domaine.
• La courbe d'apprentissage : nouveaux principes, nouveaux patterns, nouveaux processus.
• Seulement pertinent s'il existe une certaine complexité dans le problème à résoudre (business domain complexity).
  • Pas nécessaire pour des applications qui font du CRUD ou qui sont data-driven.
• Convaincre une équipe ou une entreprise à l'utilisation et les bénéfices du DDD.

• Problème du domaine: Un problème précis sur lequel le logiciel tente de solutionner.
• Core domain:
• Sub-domains: Applications ou fonctionnalités séparées que le logiciel doit supporter ou intéragir avec.
• Bounded-context: Une responsabilité précise, avec des frontières explicites qui séparernt des autres parties du système.
• Context-mapping: Le processus de délimiter les contextes délimités (bounded context), leurs relations entre chacun.
• Shared kernel: Partie du modèle qui est partagé par deux ou plusieurs équipes, qui sont d'accord pour ne pas le changer sans collaborer.
• Ubiquitous language: Un langage qui utilise des termes du modèle du domaine que les développeurs et les experts du domaine utilisent pour communiquer à propos du système.

The Domain Layer is responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure.This layer is the heart of business software.

– Eric Evens, Domain-Driven Design

Anemic focalise sur l'état d'un objet, alors que le rich domain models focalise sur le comportement et les règles d'affaires du domaine. Quoique le modèle anémique peut être partfait pour le CRUD, celui-ci constitue un anti-pattern dans le contexte du DDD.

• Domain-Driven Design Fundamentals

• An Introduction to Domain-Driven Design - DDD w/ TypeScript
• Implementing SOLID and the onion architecture in Node.js with TypeScript and InversifyJS

• Modular Monolith with DDD, Design and Implementation of a DDD-Based Modular Monolith