Geo*_*uer 7 domain-driven-design aggregateroot
采用有效聚合设计中提出的具有多个版本的产品的域.在本文中,Vaughn得出的结论是,Product和Release都应该是它们自己的聚合根.
现在假设我们添加了一个功能
我不是具有特定需求的PM,但他们希望能够在UI中对发布进行排序似乎是合理的.
我不确定这应该如何运作.每个Release都有自己的订单属性,但重新排序会涉及在同一个交易中更改多个聚合.另一方面,如果该信息存储在Product聚合中,您必须拥有一个product.setRelaseOrder(ReleaseId[])类似于奇怪的数据的方法,以存储在与Releases完全不同的地方.更糟糕的是,添加一个版本将再次涉及修改两个不同的聚合!我们还能做什么?ProductReleaseSortOrder可以是它自己的聚合,但这听起来完全荒谬!
那么该怎么办?目前我仍然倾向于let-product-manage-it选项,但这里的正确性是什么?
因此,产品和发布都是 AR。发布通过 AggregateId 与产品关联。您想获取按某项订购的给定产品的所有版本列表吗?
由于排序是聚合的属性,因此应该在 Product 上设置它,但 Releases 也是 AR,您不应该访问 Product AR 中的 Release 存储库(每个 AR 都应该有自己的存储库)。
我只需创建一个带有productId 和order 参数的ReleaseQueryService 并调用ReleaseRepository.loadOrderedReleasesForProduct(productId, order)。
我还会考虑分离上下文,也许发布演示的模型应该在另一个上下文中?在示例中,附加的 AR ProductReleases 仅用于查询。