知道何时对领域关系进行建模以及如何处理上下文关系
我是领域建模的新手，所以请原谅我问一些基本问题。 我的第一个问题是关于了解何时对域关系进行建模。 我发现有时我觉得所有类似乎都以某种方式与大多数其他类相关，并且我不清楚何时应该直接建模这些关系（通过在一个类中保留对另一个类的引用）。
例如，假设我有一个与订单集合相关的 Person 类，并且每个订单与产品集合相关（请原谅这个缺乏想象力的示例）。 这些实体中的每个实体在数据库中都有一个对应的表。 如果我正在编写一些处理与某个人关联的产品（通过该人的订单）的客户端逻辑，那么拥有一个 Person.Products 集合似乎很诱人，特别是因为我可以编写一些 SQL 来获取该集合，而无需拉回 Persons Orders 集合。 这是好的设计还是坏的设计？ 如果处理这个问题更好的方法是什么？
其次，关系本质上是情境性的情况又如何呢？ 继续前面的示例，我想在人员方法中运行的某些业务逻辑需要处理包含特定产品的人员的所有关联订单（即人员的订单集合的子集）。 我可以构造一些 SQL 来非常轻松地返回这个子集。 问题是我在哪里公开结果？ 我是否应该在 Person 上放置一个方法，该方法接受 Product 参数并返回 Orders 集合，以便客户端代码如下所示？
person.OrdersContaining(Product p)
实体是否应该有多个像这样的方法来公开其关系的不同子集，或者一个人是否应该只有一个 Orders 集合并以其他方式处理子集？
谢谢
I am new to Domain Modelling so forgive me for asking a couple of elementary questions. My first question is about knowing when to model domain relationships. I find sometimes I feel like all classes appear to be related in some way to most others and I am unclear about when I should model these relationships directly (by holding a reference in one class to another).
For example, say I have a Person class that is related to a collection of Orders and each Order is related to a collection of Products (forgive the unimaginative example). Each od these entities had a corresponding table in the database. If I am writing some client logic that deals with the Products that a Person is associated with (through that persons orders) it seems temping to have a Person.Products collection, especially as I could craft some SQL to get this collection without the need to pull back the Persons Orders collection. Is this OK or bad design? If what would be the better way to handle this?
Secondly, what about situations where relationships are contextual in nature? Continuing with the previous example say that some business logic that I want to run in a person method needs to deal with all of the Person's associated Orders that contain a specific Product (i.e. a subset of the Person's Orders collection). I can construct some SQL that will return exactly this subset very easily. The question is where do I expose the results? Should I put a method on Person that takes a Product parameter and returns the Orders collection so that client code looks like this?
person.OrdersContaining(Product p)
Should entities have multiple methods like this to expose different subsets of their relationships or should a Person just have a single Orders collection and subsets be handled in some other way?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
所有关系都是上下文相关的。
如果用户请求您提供某人已购买的产品列表，那么他们就定义了一个上下文，其中一个人与产品相关联。 没有上下文，就没有关系。
有一种常见的误解，认为应用程序只有一个域模型。 这与事实相差甚远。 原则上，每个功能都有不同的领域模型。
您应该将每个功能视为系统将支持的唯一功能。 将现有代码视为重用机会； 不多也不少。 并通过不懈的重构来使事情变得干燥。
All relationships are contextual.
If a user requests that you provide a list of products that a person has purchased, they have defined a context in which a Person is associated with Product. Without a context, there are no relationships.
There is a common misconception that there is one domain model for an application. This couldn't be further from the truth. In principle, there is a different domain model for every feature.
You should approach each feature as if it’s the only feature the system is going to support. Treat existing code as reuse opportunities; no more, no less. And DRY things up with relentless Refactoring.
您在软件中编码的每个一流关系都说明了您的设计意图以及您对实体如何组合在一起的理解。 以这种方式将人员和产品密不可分地联系起来可能被认为不是最佳的，因为每次你得到一个人时，你也会得到他们的产品。 这意味着人员和产品之间的关系实际上可能并不存在。
我可能更喜欢一个可以处理此类事情的
OrderService，而不是把它放在实体上 - 它会有像List这样的方法。 OrdersForPerson(Person p) ，等等。 不过，在某些框架中，将其放在实体上更为惯用——这里想到了 Rails 的ActiveRecord。Each first-class relationship you encode in your software makes a statement about your design intentions and your understanding of how the entities fit together. Inextricably linking People and Products that way might be considered less than optimal, since every time you get a Person, you also get their Products. That implies a relationship between People and Products that may not actually be present.
I'd probably prefer an
OrderServicethat could handle this kind of thing rather than putting it on the entity -- it would have methods likeList<Order> OrdersForPerson(Person p), and so on. In some frameworks it's more idiomatic to put it on the entity, though -- Rails'sActiveRecordcomes to mind here.我看到这里正在讨论两个问题：
1
）。 我们应该公开 People.getOrders() 和 Order.getOrdersForPerson(p) 吗？
2）。 我们应该公开 People.getProductsOrdered() 吗？
本能地，在做了多年面向对象的工作之后，我会对这两个问题说“不”。 但我可以证明这一点吗？ 什么启发法可以指导我们？ 一些建议：
a）。 越少越好。 每种方法都有成本。 开发时间、测试工作、文档。 你拥有的方法越多，找到你想要的方法就越困难。
b). 单一职责。 如果我们接受同时公开 People.getOrders() 和 Order.getOrdersForPerson(p) 操作系统的做法，那么哪个对象真正负责人员-订单关系。 我想说，订单的本质就是与订购者相关联，因此订单应该拥有这种关系。
C）。 解耦。 忙碌的人会订购很多东西。 您最终可能会得到一个合格的 getOrders() 方法，该方法采用其他条件，例如订购时间或订单大小。 要公开您使用订单的属性。 因此，People.getOrders(criteria) 现在用订单内容的详细信息来表示。 如果你改变订单，你就需要改变人员。 联轴器不好！ 这一点解决了产品问题。 很明显，订单本质上需要了解产品并与它们有一定程度的耦合。 人们没有这种内在的关系，因此不要将他们与产品联系起来。
d). 规模。 人们做很多事情。 他们不只是下订单。 您是否希望为 People 类所做的每件新事情进行更改？ 添加 People.getTrips()、People.getExpenseReimbursements()、People.getHeathCareClaims()。 当然不是。
不要相信“哦，用 SQL 很容易实现”的论点，在这个级别的讨论中，我们更关心的是设计良好的接口并实现职责的清晰分离。
I see two questions under discussion here:
and
1). Should we expose both People.getOrders() and Order.getOrdersForPerson(p)?
2). Should we expose People.getProductsOrdered()?
Instinctively, after doing OO things for many years, I would say "no" to both questions. But can I justify that? What heuristics would guide us? Some suggestions:
a). Fewer is better. Every method costs. Develpment time, testing effort, documentation. The more methods you have the harder it is to find the one you want.
b). Single Responsibilities. If we accept that exposing both People.getOrders() and Order.getOrdersForPerson(p) os overkill, which object is really responsible for the People-Order relationship. I would say it's the nature of Orders to relate the Orderer, hence Order should own the relationship.
c). Decoupling. Busy people order many things. You probably end up have a quialified getOrders() method, taking additional criteria such as when ordered, or order size. To expose that you use attributes of orders. So People.getOrders(criteria) is now expressed in terms of the detail of the order contents. If you change Order, you need to change People. Coupling is bad! This point addresses the Product question. It's clear that Orders intrinsically need to know about Products and have some level of coupling to them. People do not have that intrinsic relationship, hence don't couple them to Products.
d). Scale. People do many things. They don't just place orders. Would you expect to change the People class for each new thing they do? Add People.getTrips() People.getExpenseReimbursements(), People.getHeathCareClaims(). Surely not.
Don't fall for the "oh it's easy to implement in SQL" argument, at this level of discussion we're more concerned about devising good interfaces and getting a clean separation of resposibilities.