J'essaie de comprendre le concept de conception de domaine de la couche de service, à la fois les services d'application et les services de domaine. Pratiquement tous les exemples que j'ai rencontrés concernent des applications CRUD avec des bases de données. Je n'arrive pas à comprendre comment ces concepts correspondent aux applications graphiques comme l'exemple d'application que j'ai choisi pour cette question, un clone de Microsoft Paint développé en .NET/C#. J'ai lu le basic concept of a service layer in DDD et expanded explanation. J'ai choisi les couches d'application suivantes:Services de domaine et services d'application pour les applications graphiques
Infrastructure (transversal)
- Logging
données (système de fichiers)
- BitmapImage, PngImage, etc.
Domaine
- toile, l'image, la sélection, la forme, pinceau, etc.
application
Présentation (client local WPF)
- Vues
- ViewModels
Un cas d'utilisation que j'essaie de concevoir est l'utilisateur qui dessine un rectangle sur la toile. From what I've read, puisque le cas d'utilisation nécessite la coopération de plusieurs objets de domaine, un service de domaine, DrawingService, aurait du sens.
Un autre cas d'utilisation serait l'utilisateur chargeant un fichier à afficher. Encore une fois, from what I've read, puisque ce cas d'utilisation est une commande et un flux de travail, un service d'application, FileLoadingService, aurait du sens.
As Martin Fowler describes, Je crois que Microsoft Paint est suffisamment complexe pour justifier un sous-système de service, basé ici sur les comportements thématiques. Cependant, à mesure que l'application se développe, les couches de service peuvent être refactorisées pour tomber dans des partitions du modèle de domaine, par ex. CanvasService, SelectionService, etc. nécessiterait alors une autre couche d'abstraction, perhaps an application facade, maintenant que plusieurs services doivent coopérer?
Mise à jour 1:
Les premiers commentaires suggèrent l'architecture DDD n'est pas un bon moyen pour une application de dessin. Des suggestions pour une alternative?
imho une application de dessin n'est pas un très bon ajustement pour DDD. Cela utiliserait autre chose. – jgauffin
je serais d'accord. le dessin est un domaine bien compris et modélisé et il n'y a aucune raison d'essayer d'y adapter les outils tactiques DDD.tenter ainsi donnera de la friction; la raison principale est que la plupart des outils DDD sont orientés vers une architecture client-serveur, une méthodologie de persistance complexe dont aucune n'est pertinente avec un programme de dessin. – eulerfx
La plupart du temps, si vous n'avez pas besoin d'un expert de domaine, vous n'avez pas besoin de DDD. –