我正在尝试为我的公司建立一个计划应用程序，并可以使用一些建议。如果合适，我想遵循域驱动设计。
该域名由一个Show对象组成，该对象代表我们可能推广我们产品的一个贸易展览，展览或会议。它有开始和结束日期和时间，议程，发言人名单，位置等。可以通过演出完成相当多的工作，例如分配演讲者，注册与会者，取消等等。
我们通常作为一个或多个营销广告系列的一部分参与展示。活动还包含开始和结束日期以及其他信息以及我们将参加该活动的节目列表。我们可能会在特定的节目中推广多个广告系列。
可以在广告系列中添加或删除广告，并且在取消展示时，必须从与之关联的任何广告系列中删除该广告。
我首先想到的是一个Schedule聚合根，其中包含一个包含Show对象列表的Campaign实体列表。但我需要一种方法来访问独立节目 - 而节目可以与多个广告系列相关联。
查看我的用例，我正在开发一个Silverlight客户端（但也可以移动）。主视图将是一个日历类型的UI（如Outlook），它将每个Show显示为约会。还有侧栏显示具有后续任务的即将到来的节目，当前广告系列和节目。当我双击任何这些视图中的项目时，显示详细信息将显示在子窗口中。
有关如何在我的应用程序代码中对此域建模的任何建议吗？
答案 0 :(得分：3)
但我需要一种方法来访问独立节目 - 而节目可以与多个广告系列相关联。
尝试使用2个聚合根 - 显示和广告系列，而不是试图将所有内容放在计划聚合根目录下（在您自由谈论域名时不会出现在您的语言中的术语），而不是
广告系列还包含开始日期和结束日期以及其他信息以及我们将参加该广告系列的节目列表。
Campaign可能没有必要保持对Show的引用。如果show知道它宣传的广告系列，则在您显示广告系列信息时就足以找到它。
可以在广告系列中添加或删除广告，并且在取消展示时，必须从与之关联的任何广告系列中删除该广告。
No, it should not。
显示应标记为已取消，广告系列只会在必要时隐藏它。
我会从this开始。
这只是因为我试图简明起见，在我开始讨论模型之前没有引入附表。事实上，附表是应用程序的重点。附表代表所有节目。
很可能需要在您的域模型中引入Schedule。但由于我还没有听到（或者没有理解你的域名），我只想将我的应用程序命名为Scheduler。如果应用程序不仅仅是安排节目和广告系列，那么或者调度程序有限的上下文。
此外，在客户看来，Show并不一定了解广告系列。在我们的所有讨论中，他们只提到将节目分配给广告系列。
如果Show必须存在于“独立版本”中，那么它就是一个聚合根（在Schedule下推送它不会改变一个东西，只会添加一个抽象层。显示仍然独立于Campaigns）。如果需要弄清楚Campaign / s Show与“独立版本”相关联，则应该有一个关联Show-＆gt; Campaigns。尽管它可能与域名有点矛盾，但您可以将其视为牺牲品。
我们用清晰的原创力来表达自己的交易能力（Uncertainty principle可以在这里用作一个很好的类比）。毕竟 - 无论如何，我们无法完全彻底地捕捉心理模型。
从逻辑上讲，我同意你的观点，但我也希望确保所有已分配给它的节目共享一个广告系列实例。
您应该关注域对象的生命周期。
对象的构造和重建之间存在巨大差异。通常，Campaign仅构建一次，之后 - 它将仅从数据存储重建。如果您确保同一个Campaign的不同实例（从域角度来看）无法保存两次 - 通常就足够了。
这就是我最初认为Campaign是根的原因，但这样做忽略了将会有不属于广告系列的节目的现实。
哎呀......你是对的。