域模型对象中包含哪些内容，服务中包含哪些内容？ [英] What goes in your domain model objects and what goes in your services?

问题描述

在领域驱动的设计中，您要使用非贫乏的领域模型，您如何决定要在领域对象中实现什么与面向服务的方法呢？

In a domain driven design where you're going for a non-anemic domain model how do you decide what to implement in your domain objects vs. service oriented methods?

编辑：我用一个示例以不同的方式问了这个问题，并得到了更好的答案这里

I asked this a different way with an example and got much better answers here

推荐答案

DDD的思想是域模型包含您的数据和大多数业务逻辑。这些服务通常处理这些结构的持久性。

The idea of DDD is that the domain model contains your data and most of the business logic. The services normally deal with persistence of these structures.

然后，在所有中间情况下，业务流程都包含多个不变地更改/修改域对象的步骤。您通常使用服务来实现某些过程。因此，通常您将使用服务的结果更新域对象。您从不让域对象实现自己调用服务！

Then there's all those in-between cases where the business process consist of multiple steps that invariably change/modify the domain objects. You're normally using services to realize some process. So normally you are updating the domain objects with results from the services. You never let the domain object implementations call services by themselves !

因此，看到这样的代码很常见：

So its quite common to see code like this:

if (order.isValidForPurchase() && orderValidatorService.isValidOrder( order))
    orderService.order( order)

仅因为部分真相是订单对象已知的，而有些则需要 orderValidatorService 。可以说这两行代码也可以放在 orderService.order 方法中。

Simply because parts of the truth is known to the order object, and some requires external data known to orderValidatorService. Arguably these two lines of code could also be inside the orderService.order method.

我认为这样做总是值得的研究这些过程中如何存在许多领域对象；有时通过提出比您最初想象的更多的概念可以获得很多好处。这实际上是业务流程状态和对象模型的交集。通常，DDD模型倾向于试图从过于结构化的角度来捕获域，而IMO却忽略了核心过程。因此，如果您过于结构化，我认为您可以创建一个 Order 对象。如果您添加流程，则可能会执行 ShoppingCartOrder ， UnshippedOrder ， ShippedOrder ， BilledOrder 和 HistoricalOrder 。有时候，这也使您的服务集成更加简单。

I think it's always worthwhile to investigate HOW many domain objects exist in these processes;sometimes a lot can be gained by making more concepts than you initially think. It's really the intersection of business process states and object models. Often DDD models tend to try to capture the domain from a overly structural view, IMO disregarding core processes a little too much. So if you're overly structural I think you make an Order object. If you add process maybe you make ShoppingCartOrder, UnshippedOrder, ShippedOrder, BilledOrder and HistoricalOrder. This also makes your service integration simpler sometimes.

这篇关于域模型对象中包含哪些内容，服务中包含哪些内容？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！