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

Question

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

Answer 1

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

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

2）“域逻辑”包括“域对象”和“域服务”。由于各种原因（技术上和其他原因），许多体系结构采用一种设计，其中域逻辑被分成用于存储数据的对象（“域对象”）和操纵那些的对象（“域服务”）。 Martin Fowler and others have pointed out that that's not very OO因为OO概念的一个重要部分是将功能与数据结合在一起，这是正确的，但事实就是如此。域对象是数据，域服务是与数据相关的部分。

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

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

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

更简单＆＃39;应用程序的域模型和数据模型越相似，以及业务逻辑和域逻辑。但是当你增加“实用程序”时一个组成部分分歧，最终问题就分开了。