我正在設計一個應用程序，它將動態生成的表單顯示給用戶，然後他們將值輸入表單字段並提交這些值以進行持久化。該表格代表員工評估。幫助將DDD應用到動態表單應用程序
一個用例允許管理員（來自HR）定義表單域。他們應該能夠創建一個新表單，添加/刪除表單中的字段並將表單標記爲「已刪除」。
第二個用例是當經理查看錶單並將值輸入到特定員工的表單字段中時。他們應該能夠隨時保存這些值，並在爲同一員工再次查看錶單時調用保存的值。
最後，當經理滿意，他們已經針對該員工輸入的值，就可以「提交」，其持續扁平化數據轉換成用於報告數據倉庫中的表單數據。完成後，數據的「工作」副本將被刪除，以便表單在下次查看該員工時顯示空白。
我不擔心在這一點前端和客戶端和數據存儲之間坐鎮後端服務應用程序的工作。應用程序必須爲所有需要的行爲提供一個粗略的界面。
我的問題是我有多少聚合根（實際上有多少存儲庫等）？我是否將表單定義與表單數據分開，即使我在向用戶顯示錶單時都需要這兩種表單定義？
我看到兩個主要實體'EmployeeEvaluationSchema'和'EmployeeEvaluation'。 'EmployeeEvaluationSchema'實體將具有'FieldDefinition'值對象的集合，其將包含定義字段的屬性，最基本的是字段的名稱。 'EmployeeEvaluation'實體將具有'FieldValue'值對象的集合，其中包含定義中每個字段的值。在最簡單的情況下，它將具有字段名稱和值屬性。接下來，'EmployeeEvaluation'可以引用'EmployeeEvaluationSchema'來指定特定評估所依據的定義。這也可以用來在每個評估中強制執行表單定義。您將擁有兩個存儲庫 - 每個實體一個存儲庫。如果您要使用諸如NHibernate的ORM，那麼當您檢索'EmployeeEvaluation'實體時，即使存在專用存儲庫，也會檢索關聯的'EmployeeEvaluationSchema'。
從您的描述來看，這聽起來像你的對象沒有任何行爲，並且是簡單的DTO。如果是這種情況，也許你不應該打擾做DDD。你能想象你的實體沒有獲得者嗎？比DDD有更好的方法來執行CRUD應用程序。再次，這隻有在你的「域」沒有相關行爲時纔有效。
您已經掌握了我已經掌握了DDD的一個難題 - 實體中的邏輯應該與委託/與'services'協作多少。例如，在上面的情況下，我的實體上是否有Submit（）方法，還是我調用了SubmissionService.Submit（entity）？我傾向於後者，因爲我來自面向組件的BDD類型背景，並且提交過程與兩個實體一起工作（它將來源「評估」並創建具有不同模型的新「已提交評估」，並將其持久化數據倉庫使用不同的存儲庫）。 – SonOfPirate
我的經驗法則是我的實體上的方法應該限於操縱實體的內部狀態，但任何需要與外部「組件」交互的東西都由域服務管理。因此，提交過程將由一個提交服務管理，如我所說，從源創建「已提交評估」實體，將其持久存儲到數據倉庫，然後使用「評估存儲庫」刪除源「評估」。但是，鑑於這種方法，我發現我的域對象確實變得非常基於狀態，而且邏輯很少。 – SonOfPirate
是我還是你正在描述貧血域模型？大多數狀態和域服務都在做實際行爲的實體。對我來說，DDD的一大部分是關於邊界。聚合邊界和上下文邊界。總是傾向於自我包含並且不依賴於其他組件的存在。我也傾向於避免在沒有明確理由的情況下引入域名服務，這通常是域名專家使用既不是實體也不是VO而是實施者的熱量 - 一個完成特定工作並且不直接依賴於其他實體的組件工作。 –
這幾乎是我最初的想法。爲了回顯，我的服務類將具有像GetEmployeeEvaluation（empId）這樣的方法，該方法調用EmployeeEvaluationRepository.GetById（empId）方法，該方法負責返回包含Schema以及值集合的整個EmployeeEvaluation聚合根。調用服務的SaveEmployeeEvaluation（eval）方法時，它會調用忽略模式並保存值的EmployeeEvaluationRepository.Update（eval）方法。我在同一頁嗎？ – SonOfPirate
如果模式和數據（值）存儲在不同的數據庫中，它是否會改變您的想法？ （新要求） – SonOfPirate
只要您的存儲庫可以加載數據，存儲數據的位置就不那麼重要了。 ORM的一個考慮因素是，如果您爲每個實體完全分開數據庫，則除非您願意進行一些非規範化操作，否則您將不得不使用兩個存儲庫來加載數據，以便將架構作爲評估表複製爲好。 – eulerfx