Comment les vues de base de données en lecture seule s'intègrent-elles dans le modèle de référentiel?

Question

Exemple: votre base de données a une vue SQL nommée "CustomerOrdersOnHold".Cette vue renvoie un mélange filtré de champs de données client et commande spécifiques.Vous devez récupérer les données de cette vue dans votre application.Comment l'accès à une telle vue s'inscrit-il dans le modèle de référentiel?Souhaitez-vous créer un "CustomerOrdersOnHoldRepository"?Une vue en lecture seule comme celle-ci est-elle considérée comme une racine agrégée?

Answer 1

Je préférerais séparer le référentiel de lecture, de préférence même changer son nom en Finder ou Reader, le référentiel est destiné à l'utilisation du domaine et non à l'interrogation de données en lecture seule, vous pouvez vous référer à cet article et ceci qui explique l'utilisation du référentiel de formulaires séparés par le Finder.

Je recommanderais également de séparer le modèle de lecture de l'architecture du modèle d'écriture CQRS et là

Cette architecture vous permet de séparer le modèle de lecture du modèle d'écriture, même en termes de stockage de données et d'utilisation de la source d'événements.

Pour une solution intermédiaire, vous pouvez utiliser certains concepts CQRS sans la complexité de séparer la base de données en séparant simplement le référentiel des chercheurs, lisez ceci post

pour un exemple de ce type de solution (utiliser la même base de données mais séparer les référentiels des formulaires de recherche), vérifiez cet exemple

Answer 2

Vos données en lecture seule seraient considérées comme des objets de valeur dans le monde DDD.

Je place généralement des méthodes d'accès pour les objets de valeur dans des référentiels existants jusqu'à ce qu'il soit judicieux de créer un référentiel séparé.C'est similaire à une méthode qui pourrait renvoyer une liste statique d'états à utiliser sur un formulaire d'adresse:

IAddressRepository
{
  Address GetAddress(string addressID);

  List<string> GetStates(string country);
}

Answer 3

Je pense que c'est bien d'avoir un référentiel séparé comme "CustomerOrdersOnHoldRepository".L'interface du référentiel reflétera le fait que les objets sont en lecture seule (en ne définissant pas la méthode Save / Add / MakePersistent).

Depuis Comment écrire un référentiel :

... Mais il y a une autre stratégie que j'aime bien: la multiplication Dépôts.Dans notre exemple de commande, il n'y a aucune raison pour laquelle nous pouvons avoir deux référentiels: AllOrders et SurchargedOrders.Toutes les commandes représentent une liste contenant chaque commande dans le système, SurchargedOrders en représente un sous-ensemble.

Je n'appellerais pas l'objet retourné une racine Aggrgate.Les agrégats servent à la cohérence, à l'échange de données et aux cycles de vie.Vos objets n'en ont aucun.Il semble qu'ils ne peuvent pas non plus être classés comme objets de valeur («caractéristique ou attribut»).Ce ne sont que des classes autonomes.