领域服务与应用服务 [英] Domain services vs Application services

问题描述

域和应用程序服务之间的主要区别是什么?(我使用的是 NHibernate)

What is main difference between domain and application services? (I'm using NHibernate)

哪个层更适合业务逻辑?最佳做法是什么?

Which layer would be better for business logic? What's best practice?

-S# 架构使用应用服务作为协调层"，但不必费心解释为什么它不是领域服务，而应该是业务逻辑.

-S# Architecture uses application services as "coordination layer" but don't bother to explain why it's not domain service where should be business logic.

推荐答案

你的里程可能很多，但我会尽量根据我如何使用它们来定义.不管你的持久层是什么，我都会将它们定义为实际使用:

Your mileage may very, but I will try to define based on how I have used them. Regardless of your persistence layer, I would define them for practical use as:

• 域服务 - 旨在确保域的完整性并促进从域中插入、创建、删除和检索数据的服务.此外，域服务可以将域对象的更高级别组合编排到视图模型中.通常，这些是存储库顶部的外观，用于隐藏一些低级实现并提供更符合 UL(无处不在的语言)的界面以帮助管理期望.

• Domain Services - Services which exist to enforce the integrity of the domain and facilitate the insertion, creation, deletion, and retrieval of data from the domain. Additionally, domain services can orchestrate higher-level combinations of domain objects into viewmodels. Often, these are facades on top of repositories, working to hide some of the low-level implementation and to provide an interface more in line with the UL (ubiquitous language) to help manage expectations.

应用服务 - 特定于域模型的实现或不依赖于域模型的服务.一个典型的例子是基于域中的状态更改或操作发送和发送电子邮件.这通常是应用程序本身的要求，并且可能没有由域模型指定.这可以在调用域服务后由应用程序服务在程序上执行，也可以作为从域服务引发的事件.

Application Services - Services which are specific to the implementation of a domain model or which have no dependency on the domain model. A classic example of this would be sending and email based upon a state change or action in the domain. This is usually a requirement of the application itself, and is likely not specified by the domain model. This can either be procedurally executed by an application service after a call to the domain service, or as an event raised from the domain service.

就像我说的，这可能不符合每个人的定义，但这有助于我确保将正确的关注点放在正确的位置.

Like I said, this might not fit everyone's definitions, but this helps me to make sure that the correct concerns go into the correct place.

至于在哪里放置业务逻辑更好 - 我实际上认为这很棘手.这种方法有不止一种类型的业务逻辑.如果有不能在域内定义的特定于应用程序的逻辑需求，我会把它放在应用程序服务层.直接影响领域的东西，不管是什么应用，我都会放在领域服务层.

As to where is the better place to put the business logic - I actually think that is tricky. There is more than one type of business logic with this style of approach. If there is an application-specific logic requirement that cannot be defined within the domain, I would put it in the application service layer. Things that directly impact the domain, regardless of the application, I would put in the domain service layer.

问题确实需要花时间来确定什么是真正的领域问题".例如，除非已知用户的电子邮件地址，否则他可能无法对某个任意应用程序发表评论.您可以争辩说这属于任一层.关键是要始终如一.

The problem is really taking the time to identify what is a true "domain concern". For example, a user might not be able to post to a comment to some arbitrary application unless his email address is known. You could argue that this belongs in either layer. The key is really being consistent.

这篇关于领域服务与应用服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！