如何处理域对象层次结构答案

【问题标题】：How to handle domain objects hierarchy如何处理域对象层次结构
【发布时间】：2015-11-09 19:05:49
【问题描述】：

我正在处理一个个人项目，用于处理体育比赛中的投注和赔率列表。所以我有一个运动->赛事->比赛->投注->奇数要处理的层次结构。

我正在尝试这样做，这也是一种练习，因为我对这些概念很陌生，关于 Teresko 在他的精彩帖子中的回答中描述的规则：

How should a model be structured in MVC? （总而言之，他的回答解释了 MVC 应用程序的模型层通常由域对象、数据映射器和服务组成）

我需要的功能之一是生成当天比赛的列表，同时显示它们所附属的运动和赛事的一些数据以及附属的投注和赔率。

我还不知道如何正确设计该层次结构。我目前的想法是假设运动、赛事、比赛等，也就是我的层次结构树的节点都是域对象，并且会有它们关联的数据映射器。我的层次结构也将是一个域对象，它将处理有关树结构的信息，并拥有自己的 dataMapper。该 dataMapper 将实现横向获取作业，例如返回当天的比赛。这最终将是 5 个不同节点数据映射器（一个用于运动，一个用于事件等）将提供给他的不同表和属性的大连接。

我真的觉得我在这里遗漏了一些东西，而且这不是要走的路。但是这种组织方式听起来很常见，所以我希望你们知道一些常见且优雅的处理方式。

提前致谢，

祝大家有个愉快的一天。

【问题讨论】：

@Hector 您能否添加一些代码来说明您当前拥有的内容？仅根据您的描述，很难确定您到底卡在哪里。
@theDmi 我很清楚这一点，但我很少看到值得通过域模型进行查询的案例。这样做会鼓励您创建不明确表达其边界的聚合根（例如，从 AR1 引用 AR2 以简化数据访问，而不是简单地通过 id 引用 AR2）。当你只关注命令时，这就是 DDD 的亮点，因为 DDD 主要是关于行为的。关注行为自然会导致适当的构图，而不是人工和不必要的构图。
@plalx 交叉引用聚合在 DDD 中不好。不管你是否使用 CQRS。但是建议使用 CQRS（你的第一条评论暗示这样做）在这里只是没有建设性，这就是我想用我的评论说的。
@theDmi 我的观点更重要的是，如果 OP 没有考虑查询，他会自动识别出像 sport->event->match->bet->odd 这样的聚合可能没有意义，而且作为一个交易边界。相反，如果他专注于Event、Match、Bet 等，这些概念附加了哪些行为以及实现这些行为需要哪些数据，他可能不会问这个问题。使用 CQRS 会强制您自动执行此操作，因为该域中没有查询，那么您还可以专注于什么而不是命令？
@theDmi 我同意我的评论并不清楚，但我会删除它。

标签： model-view-controller domain-driven-design hierarchy datamapper

【解决方案1】：

由于您使用了 DDD 标签，因此您可以考虑一下 DDD 的基本概念之一；有界上下文。

听起来你的应用程序有很多；赛程（正在进行什么比赛，地点和时间），投注（赔率，投注）等等。您的问题表明您正在尝试提出一个单一的统一模型来满足所有这些问题，这与 DDD 所需要的完全相反。如果您使用整体模型进行设计，您将被复杂性淹没。

尝试根据领域语言而不是基础架构来确定问题的所有责任之间的界限。

【讨论】：