Domain Driven Design: Domaine De Service, Service De L'Application
Quelqu'un peut m'expliquer la différence entre le domaine et l'application de services en fournissant des exemples? Et, si un service est un service de domaine, j'ai mis la mise en œuvre effective de ce service dans le domaine de l'assemblée et, si oui, aurais-je aussi injecter des référentiels dans ce domaine de service? Quelques infos serait vraiment utile.
Vous devez vous connecter pour publier un commentaire.
Services se déclinent en 3 saveurs: Services de Domaine, Services d'Application, et Services d'Infrastructure.
logique d'entreprise qui ne va pas naturellement
ajustement à l'intérieur d'un domaine d'objets, et sont PAS typique opérations CRUD – ceux qui appartiennent à un Référentiel.
externe consommateurs de parler à votre
système (pensez Services Web). Si les consommateurs ont besoin d'accéder à des opérations CRUD, ils seraient exposés ici.
résumé des préoccupations techniques (p. ex.
MSMQ, fournisseur de messagerie, etc).
Maintien des Services de Domaine ainsi que vos Objets de Domaine est raisonnable, ils sont tous axés sur le domaine de la logique. Et oui, vous pouvez injecter des Référentiels dans vos Services.
Services d'Application sera généralement utiliser à la fois des Services de Domaine et Dépôts de traiter les demandes externes.
Espère que ça aide!
(Si vous n'avez pas envie de lire, il y a un résumé à la bas 🙂
Moi aussi, j'ai eu du mal avec la définition précise de la demande de services. Bien que Vijay la réponse a été très utile pour mes processus de pensée il y a un mois, je suis venu à être en désaccord avec une partie de.
D'autres ressources
Il y a très peu d'informations sur les services d'application. Des sujets d'agrégation des racines, des référentiels et des services de domaine sont largement discuté, mais les services d'application sont mentionnés brièvement ou laissé de côté complètement.
L'article de MSDN Magazine Une Introduction À La Domain-Driven Design décrit la demande de services comme un moyen de transformation et/ou d'exposer le modèle de domaine à des clients externes, comme par exemple un service WCF. C'est de cette façon Vijay décrit les services d'application trop. De ce point de vue, les services d'application sont un interface de votre domaine.
Jeffrey Palerme articles sur l'Oignon de l'Architecture (partie un, deux et trois) sont une bonne lecture. Il traite de services d'application, comme au niveau de l'application des concepts, tels que la session d'un utilisateur. Même si cela est plus proche de ma compréhension de services d'application, il n'est toujours pas en ligne avec mes pensées sur le sujet.
Mes pensées
J'en viens à penser de services d'application, comme dépendances fourni par l'application. Dans ce cas, la demande pourrait être une application de bureau ou d'un service WCF.
Domaine
Temps pour un exemple. Vous commencez avec votre nom de domaine. Toutes les entités et tous les services de domaine qui ne dépendent pas des ressources externes sont mis en œuvre ici. N'importe quel domaine des concepts qui dépendent des ressources externes sont définis par une interface. Voici une solution possible mise en page (nom du projet en gras):
La
Product
etProductFactory
classes ont été mises en œuvre dans le cœur de l'assemblée. LeIProductRepository
est quelque chose qui est probablement soutenu par une base de données. La mise en œuvre de ce n'est pas le domaine de la préoccupation et est donc défini par une interface.Pour l'instant, nous allons nous concentrer sur la
IExchangeRateService
. La logique de ce service est mis en œuvre par un service web externe. Cependant, son concept est encore partie du domaine et est représenté par cette interface.Infrastructure
La mise en œuvre des dépendances externes font partie de l'application de l'infrastructure:
XEExchangeRateService
met en œuvre laIExchangeRateService
domaine de service en communiquant avec xe.com. Cette mise en œuvre peut être utilisé par les applications qui utilisent votre modèle de domaine, y compris par l'infrastructure de l'assemblée.Application
Noter que je n'ai pas mentionné les services d'application encore. Nous allons examiner maintenant. Disons que nous voulons vous fournir une
IExchangeRateService
de mise en œuvre qui utilise un cache pour accélérer les recherches. Le contour de ce décorateur de classe pourrait ressembler à ceci.Avis de la
ICache
paramètre? Ce concept ne fait pas partie de notre domaine, il n'est donc pas un domaine de service. C'est un de service d'application. C'est une dépendance de notre infrastructure qui peut être fourni par l'application. Nous allons introduire une demande qui illustre cela:Tout cela est réuni dans la demande comme ceci:
Résumé
Une application complète se compose de trois couches principales:
La couche domaine contient le domaine des entités autonomes et les services de domaine. N'importe quel domaine concepts (ce qui inclut les services de domaine, mais aussi les dépositaires) qui dépendent des ressources externes, sont définies par les interfaces.
L'infrastructure de la couche qui contient de la mise en œuvre des interfaces de la couche domaine. Ces implémentations peuvent introduire de nouvelles domaine non des dépendances qui doivent être fournis à la demande. Ce sont les services de l'application et sont représentés par des interfaces.
De la couche application contient la mise en œuvre de la demande de services. La couche application peut également contenir des implémentations des interfaces de domaine, si les implémentations fournies par la couche de l'infrastructure ne sont pas suffisantes.
Bien que ce point de vue peut ne pas correspondre avec le général de DDD définition de services, il le fait de séparer le domaine de l'application et permet de partager le domaine (et de l'infrastructure) assemblage entre plusieurs applications.
IExchangeRateService
interface? C'est un concept de domaine, c'est à dire quelque chose qui est inclus dans votre client omniprésente de la langue. D'autres parties de votre domaine peut dépendre de ce service, c'est pourquoi l'interface définie dans la couche domaine. Mais parce que sa mise en œuvre implique un service web externe, la mise en œuvre de la classe réside dans la couche de l'infrastructure. De cette façon, le domaine de couche est le seul souci de la logique métier.ExchangeRate
exemple, qui contient une base de devise, une devise de référence et le taux de change de valeur entre ces deux monnaies. Ces étroitement liées aux valeurs représentent le "taux de change" concept du domaine, de sorte que ceux-ci vivent dans la couche domaine. Bien qu'il puisse sembler comme une simple DTO, en DDD il est appelé un Objet de Valeur, et il pourrait contenir des affaires de la logique de la comparaison ou de la transformation des instances.sample
surDomain Services, Application Services, and Infrastructure Services
dans githubLes meilleures ressources qui m'ont aidé à comprendre la différence entre une Application et un Service de Service de Domaine a été la java de la mise en œuvre d'Eric Evans fret exemple, trouvé ici. Si vous téléchargez, vous pouvez vérifier le fonctionnement interne de RoutingService (un Service de Domaine) et le BookingService, CargoInspectionService (qui sont des Services de l'Application).
Mon " aha moment a été déclenchée par deux choses:
Du Livre Rouge (la mise en Œuvre de Domain Driven Design, par Vaughn Vernon), c'est la façon dont je comprends les concepts:
Objets du domaine (entités et des objets de valeur de) encapsuler le comportement requis par la (sous -) domaine, rendant naturelle, expressive, et compréhensible.
Services de domaine encapsuler ces comportements qui ne rentrent pas dans un unique objet du domaine. Par exemple, un livre de la bibliothèque de prêt d'un
Book
à unClient
(correspondantInventory
changements) peut le faire à partir d'un domaine de service.Services d'Application gérer le flot de cas d'utilisation, y compris toute question supplémentaire nécessaire sur le dessus de du domaine. Il expose souvent de telles méthodes au travers de son API, pour la consommation par les clients externes. Pour construire sur notre exemple précédent, notre service d'application peut présenter une méthode de
LendBookToClient(Guid bookGuid, Guid clientGuid)
que:Client
.Book
.Client
etBook
) pour gérer la domaine de la logique de prêt le livre pour le client. Par exemple, j'imagine que confirme le livre de la disponibilité est certainement partie de la logique de domaine.Une demande de service doit généralement très simple flux. Complexe de services d'application, les flux indiquent souvent que la logique de domaine n'a filtré du domaine.
Que vous pouvez espérer le voir, le modèle de domaine reste très propre de cette façon, et il est facile à comprendre et à discuter avec les experts du domaine, car il ne contient son propre, réelles préoccupations des entreprises. Le flux d'application, d'autre part, est aussi beaucoup plus facile à gérer, car il est soulagé de domaine préoccupations, et devient concis et simple.
Service de domaine est l'extension du domaine. Elle doit être considérée que dans le contexte du domaine. Ce n'est pas une action de l'utilisateur comme par exemple de fermer le compte ou quelque chose. Le service de domaine de la solution là où il n'y a pas d'état. Sinon, ce serait un objet de domaine. Domaine de service fait quelque chose qui n'a de sens que lorsqu'on les fait avec d'autres collaborateurs (domaine des objets ou d'autres services). Et que sens est la responsabilité d'une autre couche.
De service d'Application est cette couche qui initialise et supervise l'interaction entre les objets du domaine et des services. Le débit est en général comme cela: obtenir domaine de l'objet (ou les objets) à partir d'un référentiel, d'exécuter une action et le mettre (les) il y a (ou pas). Il peut faire plus, par exemple, il peut vérifier si un objet de domaine existe ou pas et de lancer des exceptions en conséquence. De sorte qu'il permet à l'utilisateur d'interagir avec l'application (et c'est probablement là où son nom provient du) - en manipulant des objets du domaine et des services. Les services d'Application devrait représentent généralement tous les possibles cas d'utilisation. Probablement la meilleure chose que vous pouvez faire avant de penser à le domaine est de créer des applications des interfaces de service, ce qui vous donnera une bien meilleure idée de ce que vous êtes vraiment essayer de faire. Ayant cette connaissance vous permet de vous concentrer sur le domaine.
Dépôts peuvent généralement être injecté dans les services de domaine, mais c'est plutôt rare scénario. C'est la couche de l'application qui le fait la plupart du temps si.
Millett,C (2010). Professionnel ASP.NET les Modèles de Conception. Wiley Publishing. 92.
Services de domaine: Un service qui exprime une logique d'entreprise qui ne fait pas partie d'un ensemble de Racine.
Vous avez 2 Total:
Product
qui contient le nom et le prix.Purchase
qui contient la date de l'achat, de la liste des produits commandés avec la quantité et le prix des produits à l'époque, et la méthode de paiement.Checkout
ne fait pas partie de l'une de ces deux modèles et concept de votre entreprise.Checkout
peut être créé comme un Domaine de Service qui récupère tous les produits et de calculer le prix total, de payer le montant total en appelant un autre Service de DomainePaymentService
avec une mise en œuvre le cadre de l'Infrastructure, et de le convertir enPurchase
.Services d'Application: Un service qui "orchestre" ou d'exercices dans le Domaine des méthodes. Cela peut être aussi simple que juste de votre Contrôleur.
C'est l'endroit où vous le faites habituellement:
Vous pouvez faire des validations ici de vérifier si un
Product
est unique. À moins d'unProduct
être unique, c'est un invariant alors que ce devrait être une partie de Service de Domaine qui pourrait être appeléUniqueProductChecker
car il ne peut pas être une partie deProduct
classe et il interagit avec de multiples Agrégats.Ici est de plein fouet l'exemple de DDD projet: https://github.com/VaughnVernon/IDDD_Samples
Vous pouvez trouver beaucoup d'exemples de l'Application de Service et un couple de Service de Domaine