oop - 了解何时对域关系建模以及如何处理上下文关系

Question

我是领域建模的新手，所以请原谅我问了几个基本问​​题。我的第一个问题是关于知道何时对域关系进行建模。我发现有时我觉得所有类似乎都以某种方式与大多数其他类相关，我不清楚何时应该直接对这些关系建模(通过在一个类中保存对另一个类的引用)。

例如，假设我有一个与 Orders 集合相关的 Person 类，并且每个 Order 都与 Products 集合相关(请原谅这个缺乏想象力的例子)。这些实体中的每个 od 在数据库中都有一个对应的表。如果我正在编写一些处理与 Person 关联的产品的客户端逻辑(通过该人的订单)，那么拥有 Person.Products 集合似乎很诱人，特别是因为我可以制作一些 SQL 来获取此集合而无需拉回 Persons Orders 集合。这是好的还是坏的设计？如果处理这个问题的更好方法是什么？

其次，关系本质上是上下文的情况呢？继续前面的示例，说我想在人员方法中运行的一些业务逻辑需要处理包含特定产品的人员的所有关联订单(即人员订单集合的子集)。我可以构造一些 SQL 来很容易地返回这个子集。问题是我在哪里公开结果？我是否应该在 Person 上放置一个方法，该方法接受 Product 参数并返回 Orders 集合，以便客户端代码看起来像这样？

person.OrdersContaining(Product p)

实体是否应该有多个这样的方法来公开它们关系的不同子集，或者一个人是否应该只有一个 Orders 集合并以其他方式处理子集？

谢谢

Answer 1

我在这里看到两个正在讨论的问题:

People --- Order

和

People --- Order --- Product

1)。我们是否应该同时公开 People.getOrders() 和 Order.getOrdersForPerson(p)？

2)。我们应该公开 People.getProductsOrdered() 吗？

本能地，在做了多年面向对象的事情之后，我会对这两个问题说“不”。但我能证明这一点吗？什么样的启发式方法会指导我们？一些建议:

一种)。越少越好。每种方法都需要成本。开发时间、测试工作量、文档。您拥有的方法越多，就越难找到您想要的方法。

乙)。单一职责。如果我们接受暴露 People.getOrders() 和 Order.getOrdersForPerson(p) 操作系统的过度杀伤力，那么哪个对象真正负责 People-Order 关系。我会说订单的本质是关联订购者，因此订单应该拥有这种关系。

C)。脱钩。忙碌的人会订购很多东西。您可能最终有一个合格的 getOrders() 方法，采用其他标准，例如订购时间或订单大小。要公开这一点，您可以使用订单的属性。所以现在 People.getOrders(criteria) 用订单内容的细节来表示。如果您更改订单，则需要更改人员。耦合不好!这一点解决了产品问题。很明显，订单本质上需要了解产品并与它们有某种程度的耦合。人们没有那种内在的关系，因此不要将它们与产品联系起来。

d)。规模。人们做很多事情。他们不只是下订单。您是否期望为他们所做的每一项新事物更改 People 类？添加 People.getTrips() People.getExpenseReimbursements()、People.getHeathCareClaims()。肯定不是。

不要相信“哦，在 SQL 中很容易实现”的论点，在这个级别的讨论中，我们更关心的是设计好的接口(interface)和清晰地分离职责。