领域对象/服务和业务逻辑层
软件架构中的领域对象和领域服务是什么？我不熟悉它们或者它们与业务逻辑层有何不同？
What are domain objects and domain services in software architecture? I am not familiar with them or how they differ from the business logic layer?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
不同的人使用这些术语的方式有所不同，但我的看法是：
1）“业务”和“域”大致是同义词。 “域”更笼统一些，因为它并不假设您正在编写业务应用程序。因此，如果我们正在编写科学应用程序或游戏，我们可能更愿意将代码的相关部分称为“域”代码而不是“业务”代码。因此，在本解释的其余部分中，我将使用“域”，因为它更通用。
2）“领域逻辑”包括“领域对象”和“领域服务”。由于各种原因（技术和其他原因），许多体系结构采用了一种设计，其中域逻辑被分为用于存储数据的对象（“域对象”）和操作这些数据的对象（“域服务”）。 Martin Fowler 和其他人指出这不是非常面向对象，因为它是面向对象的重要组成部分概念是将功能与数据放在一起，这是正确的，但事实就是如此。领域对象是数据，领域服务是与数据相关的部分。
3) 在领域驱动设计中，我们的想法是回到真正的 OO 设计，因此各种服务方法都会回到领域对象，这样你就拥有了 OO 意义上的对象，而不是有时所谓的“贫血” ” 对象。在 DDD 中，域对象本身更加健壮，因此它们形成了域逻辑。实际上，可能仍然存在一些领域服务，但在 DDD 中，这通常比在更传统的领域对象与服务模型中要小。
Different people use these terms in somewhat different ways, but here's my take:
1) "Business" and "domain" are roughly synonyms. "Domain" is a bit more general in that it doesn't make the assumption that you're writing a business application. So if we were writing a scientific app or a game, we might prefer to refer to the relevant part of the code as "domain" code rather than "business" code. So in the remainder of this explanation I'll use "domain" since it's more general.
2) "Domain logic" comprehends both "domain objects" and "domain services". For various reasons (technical and otherwise) many architectures employ a design where the domain logic is divided into objects for storing data ("domain objects") and objects that manipulate those ("domain services"). Martin Fowler and others have pointed out that that's not very OO since a big part of the OO concept is to put functionality together with data, and that's right, but it is what it is. Domain objects are the data and domain services are the do-stuff-with-the-data part.
3) In domain-driven design, the idea is to get back to true OO design, and so the various service methods make their way back to the domain objects so that you have objects in the OO sense rather than what are sometimes called "anemic" objects. In a DDD the domain objects themselves are more robust and so they form the domain logic. In reality there may still be some domain services too, but this is typically smaller in a DDD than in a more traditional domain objects vs. services model.
业务逻辑层也称为域层。这是处理所有业务逻辑的层/层。
域对象和域服务是用于构建域层的类。
The Business Logic Layer is also called the Domain Layer. This is the layer/tier that handles all the business logic.
Domain Objects and Domain Services are classes that you use to build your Domain Layer.
我们需要了解应用层和领域（业务）层的职责，才能掌握其中的区别。
领域层表示业务对象，主要是业务中的实体（可能在某种程度上抽象）和领域服务。仅当业务发生变化或业务内的域上下文发生变化时，领域层才会发生变化。
应用程序层“存在”在域层之上，并且通常（最好）与域层分离，就像 ASP.NET MVC Web 应用程序一样，其中控制器部分是应用程序层，HTML 部分是表示层。应用程序层会发生变化以适应特定应用程序（或服务、API、应用程序等）的目的
We need to understand the responsibilities of the application layer and the domain (business) layer to be able to grasp the difference.
The domain layer is representing the business objects, mainly entities from the business, possibly abstracted to some degree, and domain services. The domain layer only changes when the business changes or the context of the domain changes within the business.
The application layer "lives" on top of the domain layer and is often (preferably) separated from the domain layer, like with an asp.net MVC Web application where the controller part is the application layer and the HTML part is the presentation layer. The application layer changes to accommodate the purpose of that specific application (or service, API, app etc.)
让我举一个我曾经使用过的企业应用场景的例子，来解释为什么域层和业务层都包含业务逻辑但又不同。
假设我有一个 COTS 产品，它是一个纯粹的案例管理引擎，例如 OMG CMMN 实现。业务层中的一大堆业务逻辑与数据层中的一堆实体一起工作。
现在继续假设我有两个客户是系统集成商，一个正在构建法律案例管理系统，另一个需要医疗保健案例管理。两者都是案例管理，但都有自己的领域术语、对象、过程、行业架构等。
每个领域都会添加自己的领域层，以便它们可以在各自业务领域的术语和概念中工作。
所以，是的，它包含业务逻辑，但域层是一种将通用可重用业务与特定业务封装起来的方法。
应用程序越“简单”，领域模型和数据模型以及业务逻辑和领域逻辑就越相似。但是，当您增加组件的“实用性”时，最终问题就会分开。
Let me offer this example of an enterprise application scenario i have worked with, to explain why a domain tier and a business tier both contain business logic but are different.
Suppose i have a COTS product that is a pure Case Management engine, say a OMG CMMN implementation. A whole bunch of business logic in a business tier which works with a bunch of entities from the data tier.
Now continue to suppose that I have two customers that are systems integrators, one is building a Legal case management sytem and one that wants Health care case management. both are case management, but have thier own domain terms, objects, procedures, industry architectures, etc.
Each will add thier own domain tier, so that they can work in the terms and concepts of the respective business domain.
So yes its contains business logic, but a domain tier is a way of encapsulating a generic reusable business with a specific business.
The 'simpler' the application the more similar the domain model and the data model are, and the business logic and domain logic. But when you increase 'utility' of a component diverge, eventually the concerns are separated.