Dans DDD, vaut-il la peine de définir un contexte borné pour l'accès aux fichiers?
Je conçois un éditeur comme une application de bureau qui s'ouvre, enregistre et enregistre sous forme de documents à partir de fichiers, ce qui est très courant en fait.
J'ai déjà des contextes limités pour mes règles métier.
Naïvement, je veux mettre les chemins des fichiers utilisés pour réhydrater les entités comme leurs identités et implémenter les référentiels avec accès et gestion des fichiers.
Mais j'ai le sentiment que ce n'est pas la bonne façon de gérer l'aspect fichier dans mon application.
Alors, pensez-vous qu'il peut être intéressant de concevoir un Contexte borné dédié à la gestion de fichiers?
Avez-vous des exemples de telles applications mêlant DDD et gestion de fichiers?
La plupart des exemples montrent un accès aux bases de données via des référentiels et je n'ai rien trouvé à ce sujet jusqu'à présent.
Réponses
Si je comprends bien, la gestion de fichiers ne fait pas partie de votre domaine d'activité, donc un contexte limité dédié n'a pas de sens à mon avis.
Je peux comprendre cependant que vous ne vous sentez pas à l'aise d'utiliser un chemin de fichier comme identificateur pour vos agrégats en tant que type de chaîne primitif. Je suggère donc de créer un objet de valeur , par exemple DocumentId qui encapsule cet aspect d'identification et l'abstraction du code client fonctionnant avec le modèle de domaine. Le reste de l'implémentation du référentiel fonctionne de la même manière que si vous aviez stocké le contenu dans une base de données. Utilisez une interface de référentiel dans la couche de domaine et l'implémentation du référentiel se trouve dans la couche d'infrastructure.
D'après le livre, j'ai compris un contexte borné comme un domaine de développement, suffisamment intégré pour que les gens puissent s'entendre sur les concepts représentés par les noms. Des divisions semblent se produire entre les équipes, qui travaillent sur des aspects séparés d'un problème sans communication et coordination lourdes. ( cette question traite également de cela)
Il ne semble pas que le problème que vous décrivez doive être traité par plusieurs équipes. Vous pouvez simplement déplacer la gestion des fichiers dans un module séparé à la manière d'un sous- domaine générique .