假设您有一个像这样的简单聚合根：
Playlist {
String name
List<Song> songs
add(Song song) {
// Some business rules
songs.add(song)
}
}
现在假设您想要在add(Song)依赖于其他聚合根的方法中引入业务规则。例如：一首歌曲不能出现在超过 3 个播放列表中。实现此目的的一种方法是在应用程序层获取此信息（包含歌曲的播放列表的数量）并将其传递给该add(Song)方法。
但现在进一步假设该业务规则仅适用于某些条件。例如，想象一下名称以“M”开头的播放列表没有这样的限制（完全任意）。现在，在应用程序层获取信息意味着要么在错误的级别实现域逻辑，要么获取您不会使用的数据。随着业务规则变得更加复杂，成本也会变得更高。
现在显而易见的解决方案是：使用有权访问播放列表存储库的域服务并在那里执行逻辑。虽然这有效，但我想知道是否有任何模式/架构技巧/重组可以在不使用服务封装逻辑的情况下解决这个问题？
谢谢