重构具有可变性和循环依赖性的域模型,以便为Scala提供良好的FP实

由于我的背景,我无法很好地实现适合我的域问题的域模型,并且还符合FP的良好实践,例如代码中的最小可变性.

首先,简要描述我现在的域名问题.

>主要域对象包括：事件,锦标赛,用户和团队
>团队由用户组成
>团队和用户都可以参加在赛事中举行的锦标赛
>活动包括用户和锦标赛
>参加锦标赛和赛事的团队和用户的得分,统计数据和排名将是一项重要功能.

鉴于问题的这种描述,我对域的最初想法是创建对象,其中双向循环关系是常态 – 类似于图形.我的想法是,能够访问任何给定对象的所有关联对象将为我提供最简单的路径,为我的数据编程视图,以及操纵它.

case class User(
           email: String,teams: List[TeamUser],events: List[EventUser],tournaments: List[TournamentUser]) {
}
case class TournamentUser(
                     tournament: Tournament,user: User,isPresent: Boolean){
}
case class Tournament(
                 game: Game,event: Event,users: List[TournamentUser],teams: List[TournamentTeam]) {
}

然而,随着我进一步深入研究FP最佳实践,我发现我的思维过程与FP原则不相容. Circular references are frowned upon,似乎差不多是impossibility with immutable objects.

鉴于此,我现在正在努力解决如何重构我的域以满足良好FP的要求,同时仍然保持域中“真实世界对象”的常识组织.

我考虑过的一些选择

> Use lazy val and by-name references – 我对此的疑虑是,一旦域变得不平凡,似乎变得无法管理
> Use uni-directional relationships instead – 使用此方法虽然我被迫将一些域对象作为第二类对象,但只能通过其他对象访问.我该如何选择？它们对我来说似乎同样重要.此外,这将需要“反对谷物”构建查询,以获得第二类对象的简单列表.
>使用间接并存储关系标识符列表 – 这会消除周期性依赖关系,但随后会产生更多复杂性,因为我必须编写额外的业务逻辑来模拟关系更新,并额外访问数据库以获得任何关系.

因此,我正在努力改变我的实现或我的原始模型,以实现我认为我需要的耦合,但是对于Scala来说是“正确的方式”.我该如何处理这个问题？

TL; DR – 当域似乎要求双向访问和核心可变性时,如何使用良好的FP实践对域建模？