命名像ddd構建塊（如存儲庫）的域對象

Question

當在域模型中提交概念時，存在具有名稱並且聽起來像對象但與5個主DDD建築之一的責任重疊的概念阻止命名該對象的最佳做法是什麼，或者處理可能包含或可能不包含該名稱或短語的設計？

舉一個更具體的例子，可以說我們正在設計一個DDD精神的時間跟蹤應用程序，並遇到一些領域專家稱之爲「時間日誌」的東西，該日誌應該是持有衝頭的日誌併爲所有員工提供相應的打卡時間。

有了這些信息，我最初的想法是，如果有一個名爲TimeLog的類可以查詢現有的時間條目，並且還可以保留新的或修改的時間日誌條目，這樣的類實際上扮演着DDD存儲庫的角色。爲了簡單起見，讓我們假設在經過各種討論和重構之後，我們得出結論：每次日誌條目本質上都是自己的聚合根，因此需要相應的存儲庫。

現在我們只剩下兩種命名我們的資源庫爲TimeLog的，這似乎更符合通用語言或的DDD概念行選項，我們可以把它叫做TimeLogEntryRepository這似乎符合更一般的慣例命名它們查詢/保留的聚合根之後的存儲庫。我更傾向於使用TimeLog的想法，因爲它更多地描述了它在域模型中扮演的實際角色，這反過來又有助於將設計傳達給域專家。另一方面，使用TimeLogEntryRepository的選擇遵循現有的DDD約定，因此會使開發人員更易於遵循設計。妥協也可能與TimeLog命名一致，但要讓所有存儲庫實現IRepository接口或從公共Repository基類繼承，以幫助開發人員定位和區分構成域模型的其他人的存儲庫類。我使用基類時主要關心的是，它可能會鼓勵使用標記接口或弱的不必要的基類，只是爲了組織目的而不是因爲行爲因素。

這種情況下的最佳做法是什麼？我可以看到服務可能發生的相同類型的問題，因爲它們是開發人員通常使用諸如SomeComplexActivityService中的「服務」後綴命名的另一塊典型的DDD構建塊，但對於實體和值對象而言，這實際上是非問題。我特別感興趣的是看看其他人可能不得不說，他們有更多的DDD經驗。

Answer 1

我個人比較喜歡TimeLog。

事實上，一旦您將注意力轉向業務而非技術，它會變得多麼容易。正確的命名是保持焦點銳利的主要武器。

同樣的服務 - 而不是ApplicationRegistrationService，我使用ApplicationRegistrator。

這裏是關於repositories的相當不錯的文章。

Answer 2

我第二@Arnis L.的建議。我還想補充一點，就DDD而言，您的域名應該反映您與業務分析師和其他非技術人員分享的實際UL（無處不在的語言）。所以我認爲你會和他們談談TimeLog而不是TimeLogEntryRepository。存儲庫只是一個模式，它的名字不應該在命名約定中。