之前的一篇文章談到了貧血模型，而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);
  }
}

上面的程式碼，controller講畫面傳過來的dto傳給了AccountApplicationService。
AccountApplicationService再來呼叫各種domain object。比如Account (entity), AccountRepository。

public class AccountApplicationService {
    @Autowired
    private IAccountRepository accountRepository;

    public void register(AccountDTO accountDTO){
        Account account = Account.createAccount(accountDTO.getEmail(), accountDTO.getPassword());
        accountRepository.save(account);
    }
}

infrastructure service

infrastructure service實現不依賴於業務(domain)的功能。簡單的例子來講，比如列印日誌（log），傳送郵件（如果你的應用軟體不是處理郵件問題的話）
infrastructure service位於最底層的infrastructure層。

domain service

實現domain的service類。三種service中，唯一可以寫業務邏輯的地方。
由於ddd提倡充血模型的緣故，我們在建模的時候要儘量避免製造domain service。儘量把業務邏輯放到其他的domain object中（比如entity, value object中）。

Service的比較

application service vs domain service

我想infrastructure是沒有什麼值得討論的。而application service與domain service會是讓人糾結的一個話題。
最近看到了clean architecture的設計後，感覺可能稍微容易解釋一些。(對不起，說好用只討論分層架構的，卻又提起了clean architecture，因為好難解釋…)

entities的部分對應的便是domain部分。
而application service對應的是use cases 用例。
相比於application service這個有點不知所云的名次，用例是不是更容易理解一些了（也許不是。。。）？
用例
用uml圖來畫的話，就是下面這樣的東西。

用例具體教科書般的定義，大家可以自行谷歌一下。大致就是描述一個系統大致的功能而並不描述具體內部的結構或者設計。
那在clean architecture中，domain object的操作必須通過「用例」這個入口。

那在操作層面上如何處理application service和domain service呢？

首先application service既然是入口，在一個模組中，它必定是存在的。與之相反，domain service則不一定需要。
因此，再做類設計時可以先假定domain service不存在。直接寫application service，在application service中對其他domain object進行操作。
理想情況下，application service存在的程式碼基本上就是它呼叫其他domain object的方法，具體的業務邏輯都會在domain object的方法中。所以當application service中出現if/else之類的語句，或者application service的一個方法變得很長時，我們就該警惕是不是把業務邏輯寫到了application service中。這個時候我們該考慮是否需要重構，比如把邏輯放進domain object，或者增加一個domain service。
按上面一個註冊賬號的例子，這個時候我們並不需要domain service。
但如果我們首先要確認email是否被註冊，那這時候程式碼就會變成下面那樣

public class AccountApplicationService {

    @Autowired
    private IAccountRepository accountRepository;

    public void register(AccountDTO accountDTO){
        Account account = accountRepository.find(new AccountSpecificationByEmail(accountDTO.getEmail()));
        if (account != null) {
            throw new EmailAlreadyRegisteredException();
        }
        account = Account.createAccount(accountDTO.getEmail(), accountDTO.getPassword());
        accountRepository.save(account);
    }

}

儘管方法不是很長，但判斷賬號能否被註冊的邏輯（業務邏輯）寫在了application service中。我們必須考慮將這個邏輯移到其他地方。
當然理想情況下是把它放進Account中，但查詢賬號是否存在的邏輯使用到AccountRepository，這個很難放進Account中，所以AccountService自然會是一個選擇。

public class AccountService {

    @Autowired
    private IAccountRepository accountRepository;

    public void register(String email, String password){
        Account account = accountRepository.find(new AccountSpecificationByEmail(email));
        if (account != null) {
            throw new EmailAlreadyRegisteredException();
        }
        account = Account.createAccount(email, password);
        accountRepository.save(account);
    }
}

因為不想讓domain層的東西依賴於application層的form，dto類，所以方法的引數沒有用dto。
那application service會變成

public class AccountApplicationService {

    @Autowired
    private AccountService accountService;

    public void register(AccountDTO accountDTO){
        accountService.register(accountDTO.getEmail(), accountDTO.getPassword());
    }

}

另外，有了AccountService這個類，並不是所有關於Account的邏輯都必須放進那裡。
比如AccountApplicationService裡的changePassword()，沒有必要放進AccountService中。

public class AccountApplicationService {

    @Autowired
    private IAccountRepository accountRepository;
    @Autowired
    private AccountService accountService;

    public void register(AccountDTO accountDTO){
        accountService.register(accountDTO.getEmail(), accountDTO.getPassword());
    }

    public void changePassword(String email, String oldPassword, String newPasssord) {
        Account account = accountRepository.findById(email);
        account.changePassword(oldPassword, newPasssord);
        accountRepository.save(account);
    }

}

總結

ddd中把service類分成三種。
application service, domain service, infrastructure service。
domain service中可以寫業務邏輯，但同時理想情況下我們儘量不實用domain service。
另外，我們要注意不要講業務邏輯寫到application service中。