这是一个为在家中探望病人的护士安排的应用程序.因此,很明显“Patient”是一个AggregateRoot,而“Nurse”是另一个AggregateRoot.除了指派护士使用“预约”实体访问患者之外,患者与护士没有直接联系.
现在,约会实体可以很容易地属于患者或护士AR,或者甚至两者都认为预约是两者之间的联系.因此,我也将任命变为AR.所以第一个问题是：
1)这种建模听起来不错吗？我原本试图在患者/护士AR下添加一组约会实体,但由于它确实属于两者,因此它是自己的AR是有意义的.我当时正考虑在护士/病人AR下添加一个约会ID列表以链接到他们的约会,但这意味着保存约会的交易需要同时影响多个AR,这可以从我所知道的建议糟糕的聚合设计.
假设到目前为止这种建模是有意义的,我现在需要找出执行业务规则的最佳方法,这些规则涉及当前AR的所有3个.例如,护士不能同时在一个以上的地方,因此我们不能与分配给同一护士的另一个同时创建预约.每位患者也只能预约一次.所以第二个问题是：
2)你将如何执行这些涉及多个不同AR的规则？显然,如果约会是患者或护士AR下的嵌套集合,则规则将易于实施,并且非常自包含.现在这让我怀疑我的建模是否正确.
我已经在不列颠哥伦比亚省和佐贺县/流程经理周围阅读了很多内容,但对我而言,这是同一个BC的一部分,因此不确定我是否需要任何复杂的东西.简单地使用CommandHandler来加载多个AR对象并使用它们的状态来确定是否可以创建约会是否可以接受？
如果是这样,并且与上面的Q1重叠(假设我没有在护士/患者AR下存储预约ID列表),阅读模型是轻松找到属于相应护士/患者的预约的唯一方法 – 那么基于读取模型的状态而不是存储库中的AR来强制执行业务规则也是可以接受的吗？
希望这是有道理的,并提前感谢！
Does this modelling sound right?
不(但这不是你的错 – 文学很糟糕).您的聚合将成为信息的表示,而不是在现实世界中移动的人.轮换时间表,值班者,那些可能是聚合的东西.
例如：
a nurse can’t be in more than one place at once, so we can’t create an appointment at the same time as another one assigned to the same nurse
这不是对护士的限制,这是对时间表的限制.
“上午9点,护士(身份证号码：12345)将访问病人(身份证号码：67890)”是一个时间表条目.完全可以直接管理所有计划条目.时间表的视图可能还需要包括有关护士或患者的其他信息,因此视图可以加入其他信息.
该计划成为其自己的“聚合”,使用相关ID来启用与其他信息的连接.
Would the schedule be a “NurseSchedule” or a system-wide “Schedule”?
这可能是调度护士的用例特有的.根据域名,给定的时间表可能跨越许多护士和患者.