域驅動設計：允許應用程序服務中的邏輯

我有一個如何更好地組織實現以下功能的問題。假設用戶需要登錄到系統唯一電子郵件和密碼（第一步），然後他應該確認註冊（第二步）。我有幾種選擇來構建應用程序服務/域服務/ 用戶實體之間的第一步（註冊）的實現，我不確定哪一個更好。域驅動設計：允許應用程序服務中的邏輯

第一種選擇：

AppService服務：

var existingUser = UserRepository.GetUserByEmail(email); 

if (existingUser != null) 
{ 
    throw new ValidationException(...); 
} 

var newUser = UserFactory.CreateUser(); 

newUser.Register(email, password); 

UserRepository.Save(newUser); 

// commit

所以在這裏，我們不使用任何域服務。我個人感覺不舒適的是在應用服務中檢查了電子郵件唯一性業務規則，這是一個業務規則。

第二個選項：

AppService服務：

var user = UserRegistrationDomainService.RegisterUser(email, password); 

UserRepository.Save(user); 

// commit

UserRegistrationDomainService：

User RegisterUser(email, password) 
{ 
    var existingUser = UserRepository.GetUserByEmail(email); 

    if (existingUser != null) 
    { 
    throw new ValidationException(...); 
    } 

    var newUser = UserFactory.CreateUser(); 

    newUser.Register(email, password); 

    return newUser;

}

我不喜歡這裏，是，這個解決方案是不與實現完全對稱第二步，我們只需從存儲庫獲取用戶並調用User.ConfirmRegistration（）。因此，對於註冊確認，我們不需要任何域名服務，而對於註冊，我們使用此類服務。

哪個選項更好？第一個選項的應用程序服務能否包含電子郵件唯一性驗證？

來源

2012-05-29 Markus

這屬於「會員」系統的門面，是一個服務或其他東西。我已經讀過這本書並且練習了這些單詞，但是我已經認識到，如果不很好理解，DDD會造成傷害。它促使程序員應用「配方」，因爲他們會設計模式，而不是爲當前的問題創建解決方案。 – 2012-05-30 08:31:31

就我個人而言，我認爲該生活在域的驗證（或服務的實體）。畢竟，規則是由於商業規則所必需的。

如果應用服務不負責保存用戶，那麼在選項2中最好是這樣做，這就模糊了責任界限，如果域服務處理它，它將會更好。而應用程序服務只需撥打UserRegistrationDomainService.RegisterUser(email, password)

來源

2012-05-30 07:21:56

選項1意味着唯一的電子郵件規則是特定於應用程序的。換句話說，如果你使用域dll（或jar，模塊等）在另一個應用程序中重用它，該規則將不再存在。

因爲我們可以合理地認爲該規則是應用無關的，我會選擇選項2.

另一種解決辦法是實現它的工廠來代替。畢竟，這是您創建用戶時通常放置驗證邏輯的位置（空/空名稱檢查，電子郵件格式驗證等），爲什麼不將所有創建規則集中在同一個位置？

來源

2012-05-30 12:15:58 guillaume31

域驅動設計：允許應用程序服務中的邏輯

回答

相關問題