【发布时间】:2011-08-01 03:23:47
【问题描述】:
什么是软件架构中的领域对象和领域服务?我不熟悉它们或它们与业务逻辑层有何不同?
【问题讨论】:
标签: java business-logic-layer domain-object
什么是软件架构中的领域对象和领域服务?我不熟悉它们或它们与业务逻辑层有何不同?
【问题讨论】:
标签: java business-logic-layer domain-object
不同的人使用这些术语的方式有些不同,但这是我的看法:
1) “业务”和“域”大致是同义词。 “域”更为笼统,因为它不会假设您正在编写业务应用程序。因此,如果我们正在编写科学应用程序或游戏,我们可能更愿意将代码的相关部分称为“领域”代码而不是“业务”代码。因此,在本说明的其余部分中,我将使用“域”,因为它更通用。
2) “域逻辑”包含“域对象”和“域服务”。由于各种原因(技术和其他原因),许多架构采用这样一种设计,其中域逻辑被划分为用于存储数据的对象(“域对象”)和操作这些对象的对象(“域服务”)。 Martin Fowler and others have pointed out that that's not very OO 因为 OO 概念的很大一部分是将功能与数据放在一起,这是对的,但它就是这样。域对象是数据,域服务是 do-stuff-with-the-data 部分。
3) 在领域驱动设计中,想法是回到真正的 OO 设计,因此各种服务方法会回到领域对象,这样您就有了 OO 意义上的对象,而不是有时称为“贫血”物体。在 DDD 中,域对象本身更加健壮,因此它们形成了域逻辑。实际上可能还有一些领域服务,但在 DDD 中这通常比在更传统的领域对象与服务模型中要小。
【讨论】:
业务逻辑层也称为领域层。这是处理所有业务逻辑的层/层。
域对象和域服务是用于构建域层的类。
【讨论】:
If your application naturally separates into standard layers (persistence, domain objects, business logic, presentation), you should consider using EJBs. 那么域/业务逻辑之间有什么区别?
我们需要了解应用层和领域(业务)层的职责,才能掌握区别。 领域层代表业务对象,主要是业务中的实体,可能在某种程度上抽象,以及领域服务。领域层仅在业务发生变化或领域上下文在业务内发生变化时发生变化。 应用程序层“存在”在域层之上,并且通常(最好)与域层分离,就像 asp.net MVC Web 应用程序一样,其中控制器部分是应用程序层,HTML 部分是表示层。应用层会发生变化以适应特定应用(或服务、API、应用等)的用途
【讨论】:
让我举一个我曾经使用过的企业应用场景的例子,来解释为什么域层和业务层都包含业务逻辑但又不同。
假设我有一个 COTS 产品,它是一个纯案例管理引擎,比如 OMG CMMN 实现。业务层中的一大堆业务逻辑与数据层中的一堆实体一起使用。
现在继续假设我有两个客户是系统集成商,一个正在构建法律案例管理系统,另一个需要医疗保健案例管理。两者都是案例管理,但有自己的领域术语、对象、程序、行业架构等。
每个人都将添加自己的领域层,以便他们可以在各自业务领域的术语和概念中工作。
所以是的,它包含业务逻辑,但是域层是一种将通用可重用业务与特定业务封装在一起的方式。
应用程序越“简单”,领域模型和数据模型以及业务逻辑和领域逻辑就越相似。但是当你增加一个组件的“效用”时,最终会分离关注点。
【讨论】: