域名和应用程序服务的主要区别是什么？ （我正在使用NHibernate）
哪个层对业务逻辑更好？什么是最佳做法？
-S＃架构使用应用程序服务作为“协调层”，但没有解释为什么它不是域服务，应该是业务逻辑。
答案 0 :(得分：25)
您的里程可能非常，但我会尝试根据我如何使用它们来定义。无论您的持久层如何，我都会将它们定义为实际用途：
域名服务 - 用于强制域的完整性并便于从域中插入，创建，删除和检索数据的服务。此外，域服务可以将域对象的更高级别组合编排到视图模型中。通常，这些都是存储库之上的外观，用于隐藏一些低级实现，并提供更符合UL（无处不在的语言）的接口，以帮助管理期望。
应用程序服务 - 特定于域模型实现或不依赖于域模型的服务。一个典型的例子就是根据域中的状态变化或动作发送和发送电子邮件。这通常是应用程序本身的要求，可能不是由域模型指定的。这可以是在调用域服务之后由应用程序服务程序执行，也可以是从域服务引发的事件。
就像我说的，这可能不适合每个人的定义，但这有助于我确保正确的问题进入正确的位置。
至于哪里是放置业务逻辑的更好地方 - 我实际上认为这很棘手。这种方法有多种业务逻辑。如果存在无法在域中定义的特定于应用程序的逻辑要求，我会将其放在应用程序服务层中。直接影响域的事情，无论应用程序如何，我都会放入域服务层。
问题实际上是花时间来确定什么是真正的“域名关注”。例如，除非他的电子邮件地址已知，否则用户可能无法向某个任意应用程序发布评论。你可以说这属于任何一层。关键是真的一致。
答案 1 :(得分：3)
我认为@Karsten在评论中引用的帖子比@ joseph.ferris在这里发布的最受欢迎的答案更真实。
域名服务用于“域中的重要流程或转换，这不是ENTITY或VALUE OBJECT的自然责任”（Eric Evans Domain-Driven Design）。
应用程序服务只是应用程序（或其他外部使用者）的某种外观或API，它们通常对应于应用程序的用例，是接口客户端层所需的一组应用程序操作。它们不会包含业务逻辑，也不会包含领域专家有朝一日会要求改变的任何内容。它们可能包含事务管理（工作单元），应用程序验证（验证从数据库/输入中检索的对象的状态保存到数据库），安全验证和交叉问题（如日志记录，缓存等）以及将域对象编排到视图模型中。当您拥有多个客户端（例如Web API和MVC）并且用例响应涉及多个事务资源时，它们特别有用（请参阅Martin Fowler的“企业应用程序架构模式”中的“服务层”部分）。
应用程序服务可以包含对存储库的调用以获取填充数据的域对象，然后它们可以在域对象或域服务上调用某些方法，并再次调用存储库以保留已修改的域对象。它们通常来自域服务“更广泛”，因为它们包含整个用例。
答案 2 :(得分：1)
域服务是域内的服务，包含多个需要重用的类。
Application Services是一些util类，用于完成技术工作，例如压缩或短信。
请将您的逻辑放入域对象而不是服务。在复杂域中更好地重用。