域对象/服务和业务逻辑层

Question

什么是软件架构中的域对象和域服务？ 我不熟悉它们或它们与业务逻辑层有何不同？

Answer 1

不同的人以不同的方式使用这些术语，但这是我的看法：

1）“业务”和“域”大致是同义词。 “域”更为通用，因为它不会假设您正在编写业务应用程序。 因此，如果我们正在编写科学应用程序或游戏，我们可能更愿意将代码的相关部分称为“域”代码而不是“业务”代码。 因此，在本解释的其余部分中，我将使用“域”，因为它更通用。

2）“域逻辑”包括“域对象”和“域服务”。 由于各种原因（技术上和其他原因），许多体系结构采用一种设计，其中域逻辑被分成用于存储数据的对象（“域对象”）和操纵那些的对象（“域服务”）。 Martin Fowler和其他人已经指出，由于OO概念的很大一部分是将功能与数据结合在一起，所以这并不是非常OO ，这是正确的，但事实就是如此。 域对象是数据，域服务是与数据一起做的事情。

3）在域驱动设计中，想法是回到真正的OO设计，因此各种服务方法回到域对象，以便你有OO意义上的对象而不是有时被称为“贫血”的对象“对象。 在DDD中，域对象本身更健壮，因此它们形成域逻辑。 实际上可能仍然存在一些域服务，但是DDD中的这种服务通常比更传统的域对象与服务模型中的更小。

Answer 2

业务逻辑层也称为域层。 这是处理所有业务逻辑的层/层。

域对象和域服务是用于构建域层的类。

Answer 3

我们需要了解应用层和域（业务）层的职责，以便能够掌握差异。 域层表示业务对象，主要是来自业务的实体，可能在某种程度上被抽象，以及域服务。 只有在业务发生更改或域的上下文在业务中发生更改时，域层才会更改。 应用程序层“存在”在域层之上，并且通常（优选地）与域层分离，就像asp.net MVC Web应用程序一样，其中控制器部分是应用程序层，HTML部分是表示层。 应用程序层更改以适应特定应用程序（或服务，API，应用程序等）的用途

Answer 4

让我提供一个我曾经使用的企业应用程序场景的示例，以解释为什么域层和业务层都包含业务逻辑但不同。

假设我有一个纯粹的案例管理引擎的COTS产品，比如OMG CMMN实现。 业务层中的一大堆业务逻辑，它与数据层中的一堆实体一起工作。

现在继续假设我有两个系统集成商客户，一个是建立法律案例管理系统，另一个是想要医疗保健案例管理。 两者都是案例管理，但有自己的域名条款，对象，程序，行业架构等。

每个人都会添加自己的域层，以便他们可以使用相应业务域的术语和概念。

所以是的，它包含业务逻辑，但域层是一种用特定业务封装通用可重用业务的方法。

应用程序“更简单”，域模型和数据模型越相似，以及业务逻辑和域逻辑。 但是当你增加一个组件的“效用”时，最终问题就会分开。