Problèmes d'interface utilisateur affectant la conception de domaine

Question

J'ai un domaine relativement simple, avec environ 7-8 entités principales identifiées et celles-ci pourraient être leurs propres racines agrégées. Mais il va y avoir un écran d'interface utilisateur qui va lister l'union de tous les objets dans le système, cela signifierait l'union de tous les agrégats. Une des manières dont j'ai à l'esprit est d'utiliser la composition, c'est-à-dire un agrégat de métadonnées auquel toutes les autres racines agrégées se réfèrent, ce sera une entité indépendante. Donc, pour cet écran, je peux interroger cet agrégat, les champs que je déplace vers ce nouvel agrégat sont les champs communs qui doivent être affichés dans ma grille "Tous les objets".

L'autre approche pourrait être d'avoir une méthode de service d'application qui construit la liste nécessaire pour « Tous les objets » écran en interrogeant les autres référentiels et la fusion des listes à la couche d'application et la manipulation également radiomessagerie etc.

I Je suis mal à l'aise avec la première solution car je peux voir un cas d'utilisation de l'interface utilisateur influençant ma conception de domaine mais le db fait le travail de manipulation de la pagination, la fusion des listes etc et il n'y a pas de joint toutes ces informations glanées par un simple, simple question.

La seconde solution, même si elle semble plus propre, perd en facilité et en performance.

Veuillez nous aviser.

Answer 1

Dans ce cas, je proposerais l'utilisation de read-models qui sont essentiellement des objets de valeur ou des DTO utilisés spécifiquement pour les scénarios de lecture. L'utilisation de read-models est un moyen de garder vos entités et vos RA propres. En ce qui concerne la façon dont les modèles de lecture sont créés, vous avez essentiellement deux options comme vous l'avez décrit. La première consiste à renvoyer un référentiel unique à un seul modèle de lecture qui satisfait aux exigences d'une vue donnée. Cela vous permettrait de tirer parti de la base de données pour la performance. Une autre option consiste à composer des modèles de lecture à partir de plusieurs référentiels ou services au niveau du service d'application ou de l'événement au niveau de la couche de présentation. Cette approche est plus extensible dans la mesure où les données ne doivent pas provenir de la même source de données.