域名服务VS应用服务 [英] 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:

• 域服务 - 这存在强制执行域的完整性，有利于插入，创建，删除和数据从域检索服务。此外，域名服务可以协调域对象的高层次组合成的ViewModels。通常，这些都在仓库顶部外墙，努力隐藏一些低级别的执行和提供一个接口更符合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.

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