domain-driven-design – 如何在两个聚合根目录中建立多对一的排
发布时间：2020-12-14 18:40:10 所属栏目：资源 来源：网络整理
导读：采用 Effective Aggregate Design中提出的具有多个版本的产品的域.在本文中,Vaughn得出的结论是,Product和Release都应该是它们自己的聚合根. 现在假设我们添加了一个功能 作为一名发布经理,我希望能够对发布进行排序,这样我就可以创建时间表,为用户推出更大
|
采用
Effective Aggregate Design中提出的具有多个版本的产品的域.在本文中,Vaughn得出的结论是,Product和Release都应该是它们自己的聚合根.
现在假设我们添加了一个功能 >作为一名发布经理,我希望能够对发布进行排序,这样我就可以创建时间表,为用户推出更大的史诗 我不是具有特定需求的PM,但他们希望能够在UI中对发布进行排序似乎是合理的. 我不确定这应该如何运作.每个Release都有自然的订单属性,但重新排序将涉及在同一个交易中更改多个聚合.另一方面,如果该信息存储在Product聚合中,则必须有一个类似product.setRelaSEOrder(ReleaseId [])的方法,这似乎是一个奇怪的数据存储在与Releases完全不同的地方.更糟糕的是,添加一个版本将再次涉及修改两个不同的聚合！我们还能做什么？ ProductReleaseSortOrder可以是它自己的聚合,但这听起来完全荒谬！ 那么该怎么办？目前我仍然倾向于let-product-manage-it选项,但这里的正确性是什么？ 解决方法
因此,产品和发布都??是AR. Release通过AggregateId与Product关联.您想获得按订单排序的给定产品的所有版本列表吗？
由于排序是聚合的属性,因此它应该在Product上设置,但Release也是AR,您不应该访问Product AR中的Release存储库(每个AR都应该有自己的存储库). 我只需创建一个ReleaseQueryService,它接受productId和order参数并调用ReleaseRepository.loadOrderedReleasesForProduct(productId,order). 我也会考虑分离上下文,也许发布演示文稿的模型应该在另一个上下文中？在示例中,仅用于查询的其他AR ProductReleases. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |