Je lis sur la conception pilotée par domaine depuis près de deux ans et j'ai prudemment introduit certains concepts dans mon travail quotidien ou au moins fait des plans pour que les choses que je fais régulièrement puissent être faites dans une conception pilotée par domaine.
Une conclusion à laquelle je commence à venir, en particulier en réponse à la lecture de plus sur le sourçage d'événements et la séparation des responsabilités de requête de commande (CQRS) que les objets de domaine sont peut-être destinés à être utilisés uniquement à des fins d'écriture. Pour être plus clair, il semble que ce que les gens suggèrent subtilement dans une grande partie de la documentation que j'ai lue, c'est que les objets de domaine sont responsables des opérations / calculs centrés sur le domaine, de la validation, puis sont principalement là pour fournir une route vers la persistance à travers l'infrastructure fournie dans une implémentation du référentiel. Bien que j'aime le fait que cela simplifie considérablement le modèle de domaine car il supprime la responsabilité d'exposer l'état.
S'il est effectivement exact que les objets de domaine doivent être principalement utilisés en tant qu'objets en écriture seule, cela soulève pour moi des questions auxquelles j'espère que quelqu'un pourrait répondre.
- Comment effectue-t-on des tests unitaires sur un objet qui a des setters, ou des méthodes qui modifient l'état d'un objet mais qui ne fournissent pas d'interface publique extérieure pour lire l'état à partir de tels que les accesseurs de propriété en C #? Est-il correct d'exposer l'état uniquement dans le but de rendre cet objet testable?
- Comment afficher à un utilisateur les résultats de calculs ou d'opérations effectués dans le domaine sans avoir à les conserver, puis extraire les résultats du magasin de persistance en dehors du contexte du domaine? Est-il correct d'exposer l'état uniquement dans le but d'afficher des résultats?
La règle générale est-elle que les seuls getters de propriété (get accessors) devraient être ceux qui sont également accessibles en écriture dans le domaine? Ou dit différemment, les propriétés en lecture seule devraient-elles être la seule chose à éviter car elles ne sont là qu'à des fins de lecture et ne jouent donc pas un rôle nécessaire dans le modèle de domaine réel?
Matériel connexe: