ddd的战术篇: application service, domain service, infrastructure service

最新推荐文章于 2025-03-19 09:01:55 发布

even_he

最新推荐文章于 2025-03-19 09:01:55 发布

阅读量2.2w

点赞数 9

文章标签： ddd domain-driver-design 领域驱动设计

本文链接：https://blog.csdn.net/abchywabc/article/details/79362975

版权

本文介绍了DDD中的service概念，包括application service、domain service和infrastructure service，强调了它们在分层架构中的角色。application service作为功能入口，domain service负责业务逻辑，而infrastructure service实现非业务功能。文章通过注册账号的例子，探讨了如何区分application service和domain service，并提醒开发者注意避免在application service中混入业务逻辑。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

之前的一篇文章谈到了贫血模型，而ddd是提倡充血模型的，即尽量把逻辑写在domain object中，而不是写一大堆的service类，对数据类进行操作。那么为什么ddd里会有service类呢？这篇文章会对service进行说明。

ddd中的service

首先这个在这篇文章里讨论的service基于一个前提，就是采用view, application, domain, infrastructure的分层架构。ddd提倡的架构有很多种，大家可以看前面的文章。《domain driven design》原书也是基于分层架构来论述的。至于现在流行的洋葱架构该怎么办，有机会再讲吧～
ddd中有三种service。分别是application service, domain service, infrastructure service。

application service

首先从简单的开始讲。application service是应用程序的某个功能的入口（end point）。如果你使用的是分层架构，那它是位于presentation和domain之间。
我们想像我们要写一个api用来注册账号。
url: api/accounts
method: post
如果我们使用springMVC来实现这个api的话，那Controller会调用AccountApplicationService。

@RestController
@RequestMapping("api/accounts")
public class AccountController{
   
  @Autowired
  private AccountApplicationService accountApplicationService;

  @RequestMapping(value ="", method = RequestMthod.POST)
  public void register(@RequestBody AccountDTO accountDTO){
    accountApplicationService.register(accountDTO);
  }
}