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

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

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

1）“商业”和“域”大致是同义词。 “域”更具有一般性，因为它不会假定你正在编写一个业务应用程序。所以，如果我们正在编写一个科学的应用程序或游戏，我们可能更愿意将代码的相关部分称为“域”代码而不是“业务”代码。所以在剩下的解释中，我将使用“域”，因为它更一般。

2）“域逻辑”包含“域对象”和“域服务”。出于各种原因（技术和其他方面），许多体系结构采用一种devise，其中域逻辑被划分为用于存储数据的对象（“域对象”）和操纵这些对象的对象（“域服务”）。 Martin Fowler等人指出，这不是OO，因为面向对象概念的一大部分是将function与数据结合在一起，这是正确的，但事实就是如此。域对象是数据，域服务是数据部分。

3）在领域驱动的devise中，这个想法是回到真正的OOdevise，所以各种服务方法回到域对象，使得你有OO意义上的对象，而不是有时称为“贫血“物体。在DDD中，域对象本身更健壮，所以它们形成域逻辑。实际上，也可能有一些域服务，但是在DDD中这通常比在更传统的域对象与服务模型中要小。

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

域对象和域服务是用来构build域层的类。

我们需要了解应用层和域（业务）层的责任，才能把握差异。领域层代表业务对象，主要是来自业务的实体，可能在某种程度上被抽象化，以及域服务。只有业务发生更改或业务范围内的域的上下文发生更改时，域层才会更改。应用程序层“活在”域的顶层，通常（最好）与域层分离，就像使用asp.net MVC Web应用程序，其中控制器部分是应用程序层，HTML部分是表示层。应用程序层更改以适应特定应用程序（或服务，API，应用程序等）的目的

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

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

现在继续假设我有两个客户是系统集成商，一个是build立一个法律案件pipe理系统，一个是要求医疗案件pipe理。都是案例pipe理，但有自己的领域术语，对象，程序，行业架构等。

每个人都将添加他们自己的域层，以便他们可以在各自的业务领域的术语和概念。

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

应用程序越简单，域模型和数据模型越相似，业务逻辑和领域逻辑也越相似。但是，当增加组件分歧的“效用”时，最终的担忧是分开的。