遵循DDD規範時，是否有任何價值對象工廠？

Question

最近我正在考慮過去在嘗試設計特定領域模型時遇到的一些問題，讓我們來簡單說一下Address，它可以使用給定的上下文進行編輯，但在另一個模式中是不可編輯的。我目前的想法是，我將同時擁有一個地址的價值對象版本和一個地址實體，這個地址可能附屬於某個客戶帳戶，以便派生它的身份。

現在我意識到，如果我創建一個新地址，比如用戶輸入了一個新地址，那麼我很可能還需要能夠繼續編輯該地址並編輯任何地址預先存在的地址以及在同樣有界的情況下。出於這個原因，我可以假設在這種情況下地址應該被建模爲實體而不是一個價值對象。這導致我的主要問題是，如果在修改現有數據集或創建新數據時應始終使用實體，那麼創建任何Value對象的工廠是否合理？

隨着我遵循這一思路，開始出現的規則是應該只創建值對象來表示對應用程序來說是靜態的東西或者已經保存到數據庫中的東西，但不能在當前域環境中是瞬態的。因此，我應該創造任何價值對象的唯一方式就是當它們在聚合根存儲庫內或代表聚合根存儲庫用於永久性值或在靜態值的情況下在服務中重新水合/實現時。對我來說，這似乎開始顯得很清楚，但是我擔心我沒有閱讀過其他人得出相同結論的地方。無論哪種方式，我希望有人能夠證實我的結論，或者讓我直白。

Answer 1

，可以是可編輯與不同的上下文內的可變性設置另一個

差異爲實體也可以在應用程序層中所表示內 給定上下文，但不可編輯。這是一個操作問題，可能涉及身份驗證和授權，應用程序服務是此邏輯的便利位置。 VO和實體之間的區別並不直接解決這些問題。僅僅因爲VO應該是不可變的，並不意味着實體不能改變它所引用的VO的值。例如，用戶可以引用不可變的地址值，但編輯操作可以更新用戶以引用新值。允許用戶在一個上下文中編輯地址而不在另一個上下文中可以表示爲與相應上下文相關聯的許可值。

這使我對我的主要問題是，如果你應該總是 可以修改現有的數據集或創建 新數據時使用的實體，然後它曾經是有意義的有一個工廠，用於創建 任何價值對象？

建立VO實例的工廠肯定有意義。這可以是VO類或專用對象上的靜態方法，具體取決於您的偏好。但是，不應該使用VO來解決域模型的可變性要求。相反，如上所述，這應該在應用程序層進行處理。