【问题标题】:Domain services vs Application services领域服务与应用服务
【发布时间】:2011-04-19 20:34:36
【问题描述】:

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

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

-S# 架构使用应用程序服务作为“协调层”,但不必费心解释为什么它不是领域服务应该是业务逻辑。

【问题讨论】:

标签: architecture


【解决方案1】:

您的里程可能非常多,但我会尝试根据我使用它们的方式来定义。无论您的持久层是什么,我都会将它们定义为:

  • 域服务 - 用于强制域完整性并促进从域中插入、创建、删除和检索数据的服务。此外,域服务可以将更高级别的域对象组合编排到视图模型中。通常,这些是存储库之上的外观,用于隐藏一些低级实现并提供更符合 UL(通用语言)的接口,以帮助管理预期。

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

就像我说的,这可能不符合每个人的定义,但这有助于我确保将正确的问题放在正确的位置。

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

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

【讨论】:

    【解决方案2】:

    我认为@Karsten 在他的评论中引用的帖子比@joseph.ferris 在此处发布的最受好评的答案更真实。

    领域服务用于“领域中的重要过程或转换,它不是实体或价值对象的自然责任”(Eric Evans 领域驱动设计)。

    应用程序服务只是您的应用程序(或其他外部消费者)的某种外观或 API,它们通常对应于应用程序的用例和是接口客户端层所需的一组应用程序操作。它们不包含业务逻辑或领域专家有一天可能会要求更改的任何内容。它们可能包含事务管理(工作单元)、应用程序验证(验证从数据库检索的对象的状态/保存到数据库的输入)、安全验证和横切关注点,例如日志记录、缓存等,并将域对象编排到视图模型中。当您有多个客户端(例如 Web API 和 MVC)并且用例响应涉及多个事务性资源时,它们特别有用(参见 Martin Fowler 的企业应用程序架构模式中的“服务层”部分)。

    应用程序服务可以包含对存储库的调用以获取填充数据的域对象,然后它们可能会调用域对象或域服务上的某些方法并再次调用存储库以持久化修改后的域对象。它们通常比域服务“更广泛”,因为它们包含整个用例。

    【讨论】:

      【解决方案3】:
      • 域服务是域中的服务,由多个需要重用的类组成。

      • 应用程序服务是 util 类,在其中完成压缩或短信等技术性工作。

      请将您的逻辑放入域对象而不是服务中。在复杂领域中更好地重用。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2011-10-21
        • 1970-01-01
        • 1970-01-01
        • 2015-12-30
        • 2012-02-04
        • 2010-10-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多