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 1).
On doit, entre autre :
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).
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.