Architecture propre: Utilisez un boîtier couvrant plusieurs éléments de l'interface utilisateur
Donc, je cherche actuellement à écrire un projet en utilisant une architecture propre. C'est un projet de moteur unity qui ne rend pas la tâche plus facile.
La question que je rencontre est cependant beaucoup plus fondamentale et a à voir avec le fait que tous les exemples d'utilisation de l'architecture propre que j'ai vus semblent être plutôt simples principalement crud et sans plusieurs étapes.
Maintenant, les cas d'utilisation (de haute définition de cockburn) que je souhaite mettre en œuvre impliquent quelques étapes:
- L'utilisateur crée un élément
- L'utilisateur met des informations sur l'élément
- L'utilisateur crée des éléments supplémentaires et les relie au premier
Maintenant, dans le sens de l'utilisation traditionnelle, comme décrit par une architecture propre avec un port d'entrée et un port de sortie, je ne sais pas comment modéliser ce flux de travail en tant que cas d'utilisation unique car il s'étend sur plusieurs éléments d'interface utilisateur avec leurs propres présentateurs et le flux de travail lui-même est déclenché de profondeur dans une hiérarchie de présentatrice qui n'a rien du tout à voir avec l'exécution de ce flux de travail de côté de la formule de départ.
Je souhaite que l'application soit aussi lâchée que possible, donc je ne souhaite pas introduire un accouplement serré via un objet de Dieu qui contient des références à tous les présentateurs nécessaires et implémente le port de sortie.
J'ai une solution plutôt pratique en ayant simplement la majeure partie de l'interface de l'interfaction de l'état des changements d'État dans les référentiels, cependant, comme indiqué aujourd'hui avec des collègues conduit à un peu de confusion de la manière dont le flux de données fonctionne et que nous avons des personnes optant pour Avoir des cas d'utilisation, les changements d'état de l'interface utilisateur deviennent plutôt que dans:
outputPort.ChangeToInputDetailsState()
que je pense que je pense que le principe que les cas d'utilisation ne devraient pas se soucier de la manière dont ils sont appelés, etc.
Si quelqu'un a un exemple d'utilisation dans l'architecture propre demandant des informations complémentaires ou en général toute source d'informations sur l'utilisation de l'architecture propre avec des cas d'utilisation plus complexes dans un environnement piloté par l'interface utilisateur, je serais assez heureux.
EDIT: Plus de détails à la demande
Pour élaborer un peu ce que je veux dire avec plusieurs éléments de l'interface utilisateur, car il a été demandé dans les commentaires. Je ne peux pas donner de détails sur le projet spécifique, mais je peux essayer de faire un analogon.
Cas d'utilisation (Définition des cockburn) est quelque chose comme:
Nom: enregistrez et téléchargez la vidéo
Acteur principal: Utilisateur
Pas:
- Enregistrer une vidéo
- Annoter et couper la vidéo
- Télécharger la vidéo sur le serveur
Maintenant, ceux-ci parcourent plusieurs éléments d'interface utilisateur dans le sens que les étapes 1, 2 et 3 nécessitent différentes parties de l'interface utilisateur avec leur propre sublogique à compléter, ce qui est utilisé à partir de plusieurs points. Je ne suis pas sûr que cette définition de cas d'utilisation puisse être mappée 1: 1 dans une case d'architecture propre. Si cela peut être alors le port d'entrée/sortie devra être capable d'orchestrer toutes ces différentes parties d'interface utilisateur qui peuvent être utilisées elles-mêmes par des cas d'utilisation différents.
Élaborer de comme ça que je pense que mon problème contient également une variante de la question de la réutilisation des composants de l'interface utilisateur dans un cas d'architecture propre où il pourrait y avoir plus d'un cas d'utilisation associé à un seul contrôleur/présentateur.
Edit 2: Élaborer simplement en utilisant des fonctions sur le port Outport qui retourne après avoir obtenu les informations nécessaires.
Le problème que je vois ici est que, dans des ports/présentateurs de sortie d'architecture propre, j'ai toujours regardé Dumb (au sens de toute logique) et que toute la logique commerciale tombe dans le domaine des cas d'utilisation.
Si je devais cependant seulement appeler un autre cas d'utilisation pour obtenir mes informations supplémentaires au lieu de la rétablir dans la couche de présentation, je ne seriez pas en mesure d'ouvrir une autre interface utilisateur car les cas d'utilisation ne le savent même pas.
Bien que cela soit techniquement possible de faire fonctionner l'architecture propre de tous les scénarios, elle rompre assez rapidement lorsque l'application se développe .
Comme vous l'avez mentionné, les œuvres de crud, comme vous l'avez mentionnée, mais ce n'est pas un accident, il n'y a pas d'autres exemples à trouver. En outre, si vous jetez un coup d'œil à Projet de oncle Bob , vous verrez que c'est assez encombrant (c'est-à-dire non-maintenable) même à plus petite échelle.
Ce que je dis, c'est que c'est la mauvaise conception d'utiliser, en particulier dans un scénario UI-lourd. L'architecture propre indique que l'interface utilisateur est un détail, quand dans ce cas, ce n'est évidemment pas (et je ne discuterais ni dans la plupart des autres cas).
En architecture propre, un cas d'utilisation est composé de trois composants: une demande, un gestionnaire et une réponse.
Une demande contient une entrée utilisateur. Notez que la demande elle-même est également une entrée, il n'est donc pas impossible d'avoir une demande vide, bien que les demandes généralement contiennent au moins un ID pour une ressource.
Le gestionnaire appartient à cette demande spécifique et rien d'autre. Le gestionnaire est comme la colle dans le flux de données:
- Il valide la demande (vous voudrez peut-être déléguer cela pour séparer les validateurs de demande)
- il rassemble les données nécessaires de la base de données ou de l'API externe
- il crée (initialise) des objets de domaine avec ces données et les données de la demande.
- il invoque la fonctionnalité de domaine associée à la demande
- enfin, si tout se passe bien, il persiste le nouvel état de domaine, envoie des événements, notifie API, etc.
- renvoie une réponse, si nécessaire
Dans votre question, vous mentionnez trois étapes. Vous devez vous demander s'il s'agit de trois demandes distinctes, ou est-ce peut-être une demande unique? Peut-être que vous pouvez effectuer ces trois étapes dans la couche d'interface utilisateur latérale du client, avant de créer une seule demande contenant toutes les données pour appeler la logique/règles commerciales de domaine.
Dans mon expérience, ce flux de données d'architecture propre fonctionne mieux pour les commandes.
Pour les requêtes, ce flux devient rapidement fastidieux car vous en avez généralement beaucoup plus de ne pas mentionner la pagination et le tri, etc. Si nous supposons que les commandes persistent l'état valide, nous pouvons également supposer que toutes les requêtes contiennent des états valides.