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.

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

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.

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

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.