Intriguée et inspirée par le Domain Driven Design DDD, mais avec une longue expérience du Data-Driven Development, Julie Lerman s’est battue, interrogée, et démenée pour savoir comment elle pouvait utiliser ses compétences avec le DDD. Julie, Microsoft MVP depuis 2003, travaille comme consultante et mentor sur la plateforme .NET. Elle pense que de nombreux développeurs se confrontent aux mêmes problèmes quand ils abordent le DDD. C’est pourquoi, elle partage ses expériences et les leçons qu’elle en a tirées dans trois articles du Magazine MSDN.
Julie souligne que le DDD est fait pour les comportements complexes, quelque chose que n’ont pas toutes les parties d’une application. Pour les parties contenant les simples opérations d’écriture, créer, lire, mettre à jour et supprimer, (CRUD), il est préférable de ne pas utiliser une implémentation de type DDD. Mais pour une combinaison de comportements complexes et de CRUD, Julie suggère d’identifier les parties complexes et de les séparer dans des « bounded context » distincts auxquels on applique le DDD.
Lorsqu’elle utilise le DDD et modélise le domaine, Julie se concentre sur le métier, travaillant sur les tâches et comportements attendus. La persistance des données n’est pas reliée aux problèmes métiers, et doit être une partie support ne devant pas interférer avec le design du domaine.
Un des sujets sur lequel Julie a rencontré des problèmes, est le partage de données à travers les sous-systèmes. Julie pensait que les sous-systèmes devaient obligatoirement partager les types de données, en particulier travailler avec la même table de données dans la même base de données. Le DDD lui a appris que l’on pouvait ne pas partager les mêmes modèles et par conséquent les mêmes types de données de différents sous-systèmes dans la même table et base de données. Ce n’est pas un crime de dupliquer les données ; à long terme cela peut simplifier le système en enlevant les complexités liées aux données partagées.
Finalement, Julie évoque les problèmatiques qu’elle a rencontrées en utilisant un outil d’ORM, dans son cas Entity Framework. Un des enjeux concerne les relations unidirectionnelles, qui sont les relations privilégiées lorsque l’on travaille avec le DDD. Eric Evans, auteur du premier livre sur le DDD, conseille : « il est important de restreindre au maximum les relations ». Julie utilisait des relations à double sens depuis qu’elle travaillait avec l’Entity Framework. Elle les trouvait pratiques mais a constaté qu’elles sont rarement nécessaires pour le domaine et les laisser de côté permet d’enlever la complexité induite par la gestion des relations.
Les articles de Julie sont accompagnés d’un exemple écrit en C# avec Entity Framework, le mapper objet-relationnel de Microsoft pour la plateforme .NET.