2

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

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

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

person.OrdersContaining(Product p)

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

谢谢

4

3 回答 3

2

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

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 中很容易实现”的说法,在这个级别的讨论中,我们更关心设计好的接口和清晰地分离职责。

于 2009-07-21T06:08:41.893 回答
1

所有的关系都是上下文的。

如果用户要求您提供一个人已购买的产品列表,则他们已经定义了一个人与产品相关联的上下文。没有上下文,就没有关系。

有一个常见的误解,即应用程序只有一个域模型。这与事实相去甚远。原则上,每个特性都有不同的域模型。

您应该将每个功能都视为系统将支持的唯一功能。将现有代码视为重用机会;不多不少。并通过无情的重构来干掉事情。

于 2009-11-18T03:25:03.047 回答
0

如果我正在编写一些处理与 Person 关联的产品的客户端逻辑(通过该人的订单),那么拥有 Person.Products 集合似乎很诱人,特别是因为我可以制作一些 SQL 来获取此集合而无需拉回 Persons Orders 集合。这是好的还是坏的设计?如果处理这个问题的更好方法是什么?

您在软件中编码的每个一流关系都说明了您的设计意图以及您对实体如何组合在一起的理解。以这种方式将人员和产品不可分割地联系起来可能被认为不是最佳的,因为每次你得到一个人时,你也会得到他们的产品。这意味着人与产品之间的关系可能实际上并不存在。

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

我可能更喜欢一个OrderService可以处理这种事情的东西,而不是把它放在实体上——它会有类似的方法List<Order> OrdersForPerson(Person p),等等。不过,在某些框架中,将它放在实体上更为惯用——ActiveRecord这里想到的是 Rails。

于 2009-06-06T14:57:31.297 回答