域驱动设计 – Real-World DDD：构建域层

我试图将以数据为中心的设计和开发转变为DDD,并阅读了Evans和Nillson,但是我仍然无法围绕我如何构建我的域层.我相信我目前的项目的性质并没有帮到！

有一点背景

该应用程序是管理人员评估的内部解决方案.人力资源人员将创建评估“模板”,包括团队领导和管理人员为每个直接报告完成的一系列问题.这些答案坚持审计和审查.这些评估可以用于各种各样的事情,例如公司计划的反馈,绩效评估等.

我以数据为中心的一面

不影响解决方案,但强调以数据为中心的心态,我已经有了数据库架构的愿景,并将其包含在此仅供参考(因为图片说了一千个字)：

正如预期的那样,模式被规范化,并且与我的应用程序中的数据处理方式不一致.而且,我已经省略了查找表等,以尽量减少手头存在的问题.

用例

第一个用例是检索和显示用户需要完成的评估列表.这将在用户首次登录应用程序时显示,最初似乎相对容易,但有两个皱纹：1 – 评估是基于时间的,因此可能需要每月,每年或每个“x”以雇员周年日为准的年数;并且,2 – 用户可以节省正在进行的评估,并在以后完成.因此,该清单应包含到期以及正在进行的评估.

接下来,当用户选择要执行的评估时,我需要检索该评估的所有问题(当前版本),以便我可以将它们显示给用户.在评估过程中的任何时候,用户可以保存当前的结果.只有在整个评估完成后,实际上才能“提交” – 或承诺.

第三,人力资源需要通过主管提供的回应来重新产生评估.

最后,人力资源部门能够创建和修改评估 – 并将其进行版本控制.因此,每当有人修改评估时,都会创建一个新版本,并将其作为执行的任何新评估的模板(任何正在进行的评估将继续使用其原始模板).

域模型

工作不合理,对我来说,我将有一个评估实体是一个总体根,以满足第四个用例.它将有一个小组收集的部分实体,反过来又会有一个问题实体的子集.他们都是实体,因为他们有身份(是？).评估是消耗代码用于持久性,验证等的对象(尽管部分和问题实体验证自身并将状态汇总到根评估).我的目标是使消费者的版本抽象实现在数据持久层(好的或坏的想法？)

这意味着我还将有一个AssessmentRepository来处理我的持久性,并且可能需要一个EvalFactory来创建一个新的评估.

更大的问题来自其他用例.我有一个EmployeeAssessment聚合根？还是简单的一个实体？

看一下用例,我需要使用这些信息几种方法.首先,当我生成评估列表以显示给用户时,我不仅要评估直接报告的列表,而且还需要了解我是否已经开始和/或完成了评估为该员工来自EmployeeAssessments表.另一种情况是当用户实际执行评估时,在这种情况下,我正在与EmployeeAssessments和Responses表进行交互.

从UI的角度来看,当用户执行评估时,他们什么也不了解内部数据结构等.我需要为UI提供该评估的问题列表,以显示并接受持续的响应列表.这是否带有附带存储库等的第二根？

第三个用例是类似的,因为人力资源部希望能够在稍后的日期通过响应重新生成评估.然而,我认为在执行评估时使用的相同过程可以在这里使用,因为恢复现有评估将需要相同的数据,唯一的区别是读/写能力与只读HR.

已经包装了！

好吧,我已经漫游了,我想我已经清除了我的骷髅网.我感谢任何方向,建议,批评等.正如我所说,我正在尝试跳跃,并认为我理解的概念,现在是一个应用它们的问题.谢谢！！！