DDD in Practice

Introduction

Area of application for DDD

La pratique du DDD ne s'applique pas nécessairement à tous les projets logiciels. La pratique du DDD peut apporter une certaine complexité en elle-même qui serait superflu dans certains cas. Il faut y voir une certaine complexité dans la logique d'affaire pour y recourir.

Si le logiciel est plutôt axé sur des qualités de performances, de complexité technique, de quantités importantes de données (ex: bigdata), il n'est pas nécessairement souhaitable de mettre en place du DDD dans ces genres de projets.

Pourquoi le DDD ?

Principes de base:

YAGNI: You are not gonna need it.
- Rccourci le temps nécessaire au développement
KISS: Keep it short and simple
- Aide à avoir du code maintenable

Concepts principaux du DDD

Ubiquitous Language: pont entre les développeurs et les experts, langage commun

Bounded context: Limites claires entre les différentes parties du système (ex: Sales, Support, etc)

Core domain: Focaliser sur les parties du système les plus importantes.

DDD n'est pas seulement l'écriture du code

Pour tirer partie du DDD complètement, les développeurs devrait avoir un accès facilité aux experts.
Obtain deep domain knowledge

Développeur	Expert du domaine
Défis techniques	Point de vue de l'expert du domaine
Réutilisation des connaissances techniques	Compétence pour vulgariser les problèmes du domaine

Onion Architecture

L'architecture en Onion fait en sorte que les éléments peuvent référencer ce qui est vers le centre et non le contraire. Les éléments peuvent se référencer également dans une même couche.