La conception pilotée par le domaine (i.e. Domain-Driven Design ou DDD) est une approche de conception logicielle définie par Eric Evans qui vise à accorder de l'importance au domaine métier.En effet, dans la plupart des logiciels, la logique métier qui est implémentée est ce qui constitue la plus grande valeur ajoutée puisque c'est cette logique qui rend le logiciel fonctionnel.

Pourtant très souvent une grande part des développements se concentrent sur d'autres parties comme l'interface graphique, à la persistance des données ou au partage d'informations avec des systèmes externes.

DDD n'est pas une méthode pour concevoir des logiciels mais juste une approche qui permet d'indiquer comment concevoir un logiciel en prenant davantage en compte le domaine métier.

L'intérêt de DDD est :

• Permettre à l'équipe de créer un modèle et de le communiquer aux experts métier mais aussi à d'autres acteurs de l'entreprise avec les spécifications fonctionnelles, les entités du modèle de données et la modélisation de processus.
• Le modèle est modulaire et plus facile à maintenir.
• Il améliore la testabilité et la généricité des objets du domaine métier.

L'approche DDD vise, dans un premier temps, à isoler un domaine métier. Un domaine métier riche comporte les caractéristiques suivantes :

• Il approfondit les règles métier spécifiques et il est en accord avec le modèle d'entreprise, avec la stratégie et les processus métier.
• Il doit être isolé des autres domaines métier et des autres couches de l'architecture de l'application.
• Le modèle doit être construit avec un couplage faible avec les autres couches de l'application
• Il doit être une couche abstraite et assez séparée pour être facilement maintenue, testée et versionnée.
• Le modèle doit être concu avec le moins de dépendances possibles avec une technologie ou un framework. Il devrait être constitué par des objets POCO (Plain Old C# Object). Les POCO sont des objets métier disposant de données, de logique de validation et de logiques métier. Il ne doit pas comporter de logique de persistance.
• Le domaine métier ne doit pas comporter de détails d'implémentation de la persistance.

Architecture en couches

DDD préconise de séparer le code en couche pour ne pas diluer la logique métier dans plusieurs endroits. Chaque couche a une fonction particulière qui est utilisable par d'autres couches de façon à :

• Mutualiser le code suivant une logique
• Éviter la duplication de code métier

Les 4 couches sont: :

• la couche utilisateur
• la couche application
• la couche domaine
• la couche infrastructure

La couche utilisateur
Elle présente l'information à l'utilisateur et réceptionne ses commandes. Cette couche peut faire appel à toutes les autres.

La couche application
La couche application (i.e. "application service layer") sépare la couche utilisateur de la couche domaine:

• Elle ne contient pas de code métier mais peut être amenée à contenir du code permettant de gérer des changements dans la couche utilisateur.
• Elle ne doit pas garder l'état des objets métier mais peut stocker l'état d'avancement d'une tâche de l'application.
• Elle permet d'effectuer la navigation entre les écrans de l'interface graphique et les interactions avec les couches application d'autres systèmes.
• Elle peut effectuer des validations basiques (non liées à des règles métier) sur les entrées de l'utilisateur avant de les transmettre aux autres couches de l'application.
• Elle ne doit pas contenir de logique métier ni de logique d'accès aux données.
• Cette couche peut faire appel à la couche domaine et à la couche infrastructure.

Cette couche peut permettre d'isoler la couche domaine des aspects techniques nécessaires à son fonctionnement. Elle peut contenir les services applicatifs et servir d'intermédiaire entre la couche domaine et les objets qui y font appels. Elle expose les capacités du système en proposant une abstraction à la logique du domaine contenue dans la couche domaine. Elle tends grandement à préserver le domaine en concentrant de nombreux éléments de logique applicative.

Cette couche de services sert aussi d'implémentation concrête à la frontière du contexte borné, elle peut assurer les échanges avec les autres contextes bornés en utilisant, par exemple, des services REST, des web services ou par l'intermédiaire d'un bus de communication.

La couche domaine

Elle contient les informations sur le domaine et la logique métier:

• Elle détient tous les concepts du modèle métier, les cas d'utilisation et les règles métier.
• Elle contient l'état des objets métier toutefois elle n'effectue pas directement la persistance des objets métier.
• Elle peut aussi contenir l'état d'un cas d'utilisation métier si celui-ci est formé de plusieurs requêtes de l'utilisateur.
• Elle peut contenir des objets de service si leur comportement ne peut être implémenté dans un objet métier. Les services contiennent des comportements métier qui ne peuvent pas faire partie d'un objet du modèle.
• Cette couche est le coeur du métier, elle doit être isolée des autres couches et ne peut être dépendantes de framework.
• Cette couche ne peut faire appel qu'à la couche infrastructure.

La couche infrastructure

Elle permet de fournir un lien de communication entre toutes les autres couches. D'autre part, elle contient le code de persistance des objets métier. Cette persistance n'est pas forcément dans une base de données.

Les relations entre les couches peuvent être directes toutefois il est préférable que les relations se fassent des couches hautes (par exemple la couche utilisateur) vers les couches basses (couche infrastructure).

Approche SOA

L'approche SOA (pour "Service-Oriented Architecture") ne dispense pas d'une réflexion sur le modèle métier. On pourrait croire que cette approche permet d'isoler par construction un modèle métier, pourtant dans le cas où on accorde pas assez d'importance à la conception du modèle, une approche SOA entraînera une implémentation avec les mêmes conséquences que pour architecture classique : une couche de service hypertrophiée (Fat Service Layer) et une modèle métier anémique (Anemic Domain Model).

Dans l'approche SOA, il faut donc accorder le même degré d'effort à la conception d'un domain model:

• Avant tout, isoler un domain model qui encapsulera la logique métier et les règles métiers des objets
• Implémenter le service en même temps que la couche application de façon à ce que les composants du service puissent consommer les éléments du modèle métier.
• Le service deviendra juste un "proxy" pour atteindre le modèle métier.

Préserver la couche domaine

La couche domaine ne doit pas être influencée par des éléments de la logique applicative. La logique applicative comprends la coordination entre le domaine et les services qui se trouvent dans la couche infrastructure.

Cette logique vise à répondre à des sollicitations provenant de la couche utilisateur, de la couche application mais aussi provenant d'autres domain models et de les présenter à la couche domaine. Les sollicitations peuvent aussi provenir de la couche domaine, par exemple pour notifier des changements de l'état du domaine.

Ainsi, pour préserver la couche domaine, cette logique applicative doit se trouver dans les services de la couche application ou infrastructure.