3
我們正在將現有系統轉換爲DDD，並且正在努力將我們的頭部圍繞幾個概念進行包裝。管理實體的歷史記錄對象
我們有一個名爲Animal的聚合根，它具有諸如Status和Source之類的屬性。目前該數據庫有兩個表，分別叫做StatusHistory和SourceHistory，它存儲關於動物狀態改變時的信息。這些表有時會刪除記錄，並且在從AnimalRepository獲取Animal時很少需要檢索。
所以最大的問題是它們屬於哪裏？以下是我們的一些想法：
將它們作爲不同的實體對象作爲動物聚合的一部分。並且有相應的方法允許它們被更新，例如：
Animal.UpdateStatus(newStatus)，這會通過new StatusHistory(this)對象添加到集合中。但是正如上面提到的那樣，在爲存儲庫獲取現有動物時，這些很少需要，因此我們不希望存儲庫加載它們。我們目前不使用ORM，而是使用存儲庫內的表數據網關手動映射。使每個歷史實體成爲一個聚合根。我們並不是這樣的粉絲，因爲它感覺我們並沒有真正爲域名建模，而是朝着
Active Record Pattern漂流。更新這些動物的任務必須位於動物實體之外。我們可以嘗試將這些歷史合併到另一個稱爲
AnimalHistory的聚合根中，其全部目的是維護動物的歷史。但是，再一次將移動的邏輯關於將歷史存儲在動物身上。可能像AnimalProcessingService這樣的服務，這感覺我們可能會走向貧血設計。
我希望有另一種選擇，它會爲我們提供更清潔的設計。