帮助将 DDD 应用于动态表单应用程序
我正在设计一个应用程序，它将向用户显示动态生成的表单，然后用户将在表单字段中输入值并提交这些值以进行持久化。该表格代表员工评估。
一种用例允许管理员（来自 HR）定义表单字段。他们应该能够创建新表单、在表单中添加/删除字段以及将表单标记为“已删除”。
第二个用例是当经理查看表单并向特定员工的表单字段中输入值时。他们应该能够随时保存这些值，并在再次查看同一员工的表单时调用保存的值。
最后，当经理对为该员工输入的值感到满意时，他们可以“提交”表单数据，该表单数据将扁平数据保存到数据仓库中以用于报告目的。完成此操作后，数据的“工作”副本将被删除，因此当他们下次查看该员工的表单时，该表单将显示为空。
我目前不关心前端，而是负责位于客户端和数据存储之间的后端服务应用程序。应用程序必须为所有所需行为提供粗粒度的接口。
我的问题是我实际上有多少个聚合根（以及由此而来的多少个存储库等）？即使在向用户显示表单时需要两者，我是否仍将表单定义与表单数据分开？
I am designing an application that will display dynamically-generated forms to the user who will then enter values into the form fields and submit those values for persistence. The form represents an employee evaluation.
One use case allows an administrator (from HR) to define the form fields. They should be able to create a new form, add/remove fields from a form and mark a form as 'deleted'.
The second use case is when a manager views the form and enters values into the form fields for a specific employee. They should be able to save the values at any time and recall the saved values when viewing the form again for the same employee.
Finally, when the manager is satisfied with the values they've entered for that employee, they can 'submit' the form data which persists the flattened data into the data warehouse for reporting purposes. When this is done, the 'working' copy of the data is removed so the form will display empty the next time they view it for that employee.
I am not concerned with the front-end at this point and working on the back-end service application that sits between the client and the data store. The application must provide a course-grained interface for all of the behavior required.
My question is how many aggregate roots do I actually have (and from that, how many repositories, etc)? Do I separate the form definition from the form data even though I need both when displaying the form to the user?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我看到两个主要实体：“EmployeeEvaluationSchema”和“EmployeeEvaluation”。 “EmployeeEvaluationSchema”实体将具有“FieldDefinition”值对象的集合，其中包含定义字段的属性，最基本的是字段的名称。 “EmployeeEvaluation”实体将具有“FieldValue”值对象的集合，其中包含定义中每个字段的值。在最简单的情况下，它将具有字段名称和值属性。接下来，“EmployeeEvaluation”可以引用“EmployeeEvaluationSchema”来指定特定评估所基于的定义。这也可以用于在每次评估中强制执行表单定义。您将有两个存储库 - 每个实体一个。如果您要使用 ORM（例如 NHibernate），那么当您检索“EmployeeEvaluation”实体时，关联的“EmployeeEvaluationSchema”也会被检索，即使有一个专用的存储库。
I see two main entities, 'EmployeeEvaluationSchema' and 'EmployeeEvaluation'. The 'EmployeeEvaluationSchema' entity would have a collection of 'FieldDefinition' value objects which would contain the properties that define a field, the most basic being the name of the field. The 'EmployeeEvaluation' entity would have a collection of 'FieldValue' value objects which contain the values for each field from the definition. In the simplest case, it would have a field name and value property. Next, the 'EmployeeEvaluation' could have a reference to 'EmployeeEvaluationSchema' to specify which definition the particular evaluation is based on. This can also be used to enforce the form definition in each evaluation. You would have two repositories - one for each entity. If you were to use an ORM such as NHibernate, then when you retrieve a 'EmployeeEvaluation' entity, the associated 'EmployeeEvaluationSchema' would also be retrieved even though there is a dedicated repository for it.
从您的描述来看，您的对象似乎没有任何行为，并且是简单的 DTO。如果是这样的话，也许你不应该费心去做 DDD。你能想象你的实体没有吸气剂吗？有比 DDD 更好的方法来执行 CRUDish 应用程序。同样，这仅在您的“域”没有相关行为时才有效。
From your description it sounds like your objects don't have any behavior and are simple DTOs. If that is the case maybe you should not bother doing DDD. Can you imagine your entities without having getters? There are better ways to do CRUDish application than DDD. Again this is only valid if your "domain" does not have relevant behavior.