如何设计以下域的最佳方式

Question

好的，所以...我有一个名为Lead 的实体，然后当我实例化这个实体时，它应该寻找一个名为Account 的实体，并通过属性account_id 关联它们自己。 Lead 与 Account 匹配 Lead 中的两个属性 areacode 和 campaign_id。我该如何设计它以创建一个很好的面向对象？

1. Lead 中的方法matchAccount？
2. AccountsController/AccountAggregator中的方法intakeLead?
3. 另一个班级AccountMatcher 来处理它？
4. 没有。我建议...

谢谢！

Answer 1

使用 DDD，一切都与域概念和关系（不是 rdbms 关系）有关。 OOP 也不重要，因为它是一种技术方法，而您使用的是业务（域）方法。但是，您将隐式使用 OOP，因为它是对域建模的自然方式。

我不知道你的领域，但根据你对问题的描述，我认为那里没有多少 DDD，而是被 DDD 术语掩盖的旧 CRUD 思维方式。 IT 看起来您并没有确定相关的有界上下文和聚合根 (AR)。那么，这些实体可以做什么（行为）？它们是如何使用的（它们涉及的用例）？

当您执行 DDD 时，您让域告诉您哪些是对象以及它们如何相互交互。 AR 可以通过 Id“指向”另一个 AR，但是上下文和用例非常重要。而且您可以让多个 AR 对同一概念但在不同的上下文中建模，因此并非总是只有一个 Account AR 可以在任何地方使用。

花点时间忘记 OOP、ORM、rdbms 等。只关注领域以正确理解这些概念（它们可能很棘手！）及其relationships。生成的代码将是良好的 OOP，更重要的是良好的建模。之后担心持久性和rdbms。

编辑

根据 OP 和评论中的要点，我认为（我只能猜测，因为我现在不知道域）这是 Lead 的用例（表）所以，如果没有其他相关细节，我将有一项服务或类似的服务，它将采取 Lead 和 IEnumerable 来执行该行为。您向客户存储库询问潜在客户的客户，并提供匹配条件（区号和活动 ID）。

根据经验，我建议尝试剖析这些概念并尝试重新构建它们的关系，直到您确定自己理解了正确的关系。

Answer 2

在 OOP 的严格意义上，您应该使用关联来描述对象之间如何相互关联。

如果您使用方法通过键来表达关联，那么在我看来，您是在使用关系设计原则表达对象，这不是面向对象的编程。

实际上，我不知道您是否使用 OR/M 来将此类域持久保存到某个数据库，但如果您这样做，您应该能够创建实际关联并将它们映射到以您的领域将被表达为完全面向对象的编程设计的方式：

• Lead 有一个名为“Account”的属性，它将 1 个 Lead 与 1 个帐户相关联（1:1 关联）。

此外，OOP 和 OR/M，或者只是数据映射器，与人工键（单列键）而不是复合键一起工作得更好。

也许您没有使用 OR/M。然后，一个简单的解决方案是在您的类中添加一个方法，该方法将加载名为“Load”的关联而不带参数：

Lead lead = new Lead();
lead.Load();

// Now you can access "Account" association:
lead.Account.Id

显然，您可以使此解决方案复杂化，但您最终会使用自己的 OR/M，因此如果您不重新发明轮子并利用现有的任何一个，您会更好！