9.企业应用架构模式 --- 领域逻辑模式

1.事务脚本使用过程来组织业务逻辑，每个过程处理来自表现层的单个请求。大多数业务应用都可以被看做是一系列的事务。一个事务可能将某种信息看做是以特定方式组织的，然后另一事务则会改变它。在客户系统和服务器系统之间的每次交互都包含一定数量的逻辑。事务脚本将所有这些逻辑组织成单个过程，在过程中直接调用数据库，或者只通过一个简单的数据库封装器。每个事务都有自己的事务脚本，尽管事务间的公共子任务可以被分解成多个子程序。1.运行机制使用事务脚本，领域逻辑主要通过系统所执行的事务来组织。可以将两种方法来把事务脚本组织成类。最常用的方法是将数个事务脚本放在一个类中，每个类围绕一个主题将相关的事务脚本组织在一起。另外一种方法则是每个事务脚本对应一个类，此时需要使用命令模式。这种情况下应定义一个所有命令的父类，在父类中声明事务脚本逻辑适合的执行方法。将事务脚本组织成类的优点在于：允许你运行时以对象的方式来控制脚本类的实例。当然，在许多语言中你可以不使用类而使用全局函数。但是，你通常会发现实例化新的对象有助于解决与线程相关的问题，因为它比较容易实现数据隔离。2.使用时机事务脚本胜在简单。谨慎提取公共子程序可以避免很多问题，但更复杂的业务领域则需要建立领域模型。2.领域模型合并了行为和数据的领域的对象模型。领域模型创建了一张由互联对象组成的网，其中的每一个对象都代表某个有意义的个体。1.运行机制在应用程序中使用领域模型需要建立一个完整的由对象组成的层，来对目标业务领域建模。你会发现其中有的对象模拟业务活动中的数据，有的对象捕捉业务使用的规则。数据和处理一般整合在一起，从而使得数据和数据之上的操作紧密聚合。领域模型混合数据和处理过程，拥有多值属性和复杂的关联网，并且使用继承。因此，领域模型衍生出两种风格。简单领域模型看起来与数据库设计很相似，这种设计中几乎每一个数据库表都与一个领域对象对应。而复杂领域模型则与数据库设计不同，它使用继承，策略和其他设计模式，是一张由互联的细粒度对象组成的复杂网络。简单领域模型可以使用活动记录，而复杂领域模型需要使用数据映射器。使用领域逻辑的一个常见问题是领域对象过于臃肿。领域模型应当使用细粒度的对象，这些对象应有细粒度的接口。2.使用时机通常领域模型中经常能看到：多个类如何交互来完成即使很简单的任务。这也正是引起抱怨的原因 --- 在阅读面向对象的程序时，你得花费许多时间在一个个类之间跳转，以找出它们之间是如何交互的。在面向对象技术中，通过从一个对象到另外一个对象的连续传递可以把行为传给最有资格处理的对象，它同时也消除了许多条件判断行为。3.表模块处理某一数据库表或视图中所有行的业务逻辑的一个实例。面向对象的关键思想之一是将数据与该数据操作的行为绑定在一起。传统的面向对象方法基于拥有标识符的对象，就像领域模型所使用的那样。最常见的表模块例子是对数据库中的每一个表使用一个表模块。表模块可以是一个实例，也可以是一个静态方法的集合。4.服务层通过一个服务层来定义应用程序边界，在服务层中建立一组可用的操作集合，并在每个操作内部协调应用程序的响应。企业级应用通常需要提供不同种类的接口来访问内部存储的数据和所实现的逻辑。服务层定义了应用的边界和从接口客户层角度所能看到的可用操作集。它封装了应用的业务逻辑，事务控制及其操作实现中的响应协调。1.运行机制1.业务逻辑的种类像事务脚本和领域模型一样，服务层是一种组织业务逻辑的模式。将业务逻辑分成两类："领域逻辑"和"应用逻辑"。前者只与问题有关，如计算合同收入确认的策略等，而后者与应用的职责有关，如关于收入确认计算的相关事宜，通知合同管理者，集成系统等。应用逻辑有时被称为"工作流逻辑"。在避免领域逻辑的重复及利用经典模式来管理复杂性方面，领域逻辑优于事务脚本。但是将应用逻辑置于纯粹的领域对象类中也会带来一些不良后果。首先，如果在领域对象类中实现了针对具体应用的逻辑，或者依赖于针对具体应用的软件包，则会降低该类在应用之间的的可重用性。其次，如果将来需要在如工作流工具之类的软件中重现应用程序逻辑，则将两种逻辑混杂在同一个类中会使得这一工作比较困难。基于这些理由，服务层把每种业务逻辑分解成为一个单独的层，从而在获得分层的常规收益同时，使得纯粹的领域对象类可以在不同应用之间更好的被重用。2.实现方法领域外观方法和操作脚本方法是两种基本的实现方法。在领域外观方法中，服务层以领域模型之上的瘦外观集合方式实现。负责实现外观的类不包含任务业务逻辑，所有的业务逻辑均由领域模型实现。瘦外观建立了客户层与应用程序交互的边界和操作集，这正显示出服务层的定义特征。在操作脚本方法中，服务层是由一组相对复杂的类组成，这些类直接实现应用逻辑，但将领域逻辑委托给封装好的领域对象类。服务层客户所能使用的操作以脚本的方式实现，数个脚本组成一个类，一个类定义与某一个主题相关的逻辑。每一个类组成一个应用程序'服务'，通常服务类型的名字都为'xx服务'。服务层由这些应用程序服务类组成，它们之上应当扩展出一个抽象了职责和公共行为的层超类型。3.是否远程由于服务层类的接口声明一组应用操作来与客户层连接，因此从定义上说：服务层类的接口是粗粒度的。所以说，就接口粒度而言，服务层很适合于远程调用。但是远程调用的代价在于对对象分布性的处理。我的建议是，开始时仅设计一个本地调用的服务层，其方法标记中仅处理领域对象。当你需要远程调用功能时，再通过在服务层之上增加一个远程外观来实现，或者让你的服务层对象实现远程接口。4.识别服务与操作识别出服务层边界上应提供的操作十分简单。它们由服务层客户的需求决定，其中最重要的通常是用户界面。由于用户界面是为支持执行者与应用程序交互的用例而设计的，因此标识服务层操作的起点应该是用例模型和应用程序的用户界面设计。   服务层的优点在于，它定义了一个公共的应用操作结合，这一集合可以被各种客户使用，而且服务层在每个操作中都会协调应用的响应。响应可能涉及某些需要在多个事务性资源之间进行原子化处理的应用逻辑。因此，在业务逻辑中有多种客户的应用中，或者其用例中的复杂响应涉及多个事务性资源时，即使不是分布式架构，使用一个容器管理事务的服务层仍是很有必要的。比较容易回答的是什么时候不应该使用服务层。如果你的业务逻辑只有一种客户 --- 如用户界面，或者用例响应并不涉及多个事务性资源，就可能不需要使用服务层。此时，你的页面控制器可以人工控制事务并随时协调所需的响应，可能直接将这些响应发给数据源层。但是如果你能预见到第二个客户，或用例响应中的第二个事务性资源，则有必要再一开始时就设计一个服务层。

9.企业应用架构模式 --- 领域逻辑模式相关推荐

系统架构师谈企业应用架构之业务逻辑层
一.上章回顾上章我们主要讲述了系统设计规范与原则中的具体原则与规范及如何实现满足规范的设计,我们也讲述了通过分离功能点的方式来实现,而在软件开发过程中的具体实现方式简单的分为面向过程与面向对象的开发 ...
企业应用架构之业务逻辑层的顶层设计与底层思考
摘要本文将以架构的方式去分析分层结构中的业务层设计,如何写出来内聚度,高耦合的业务逻辑层,并且如何根据我们的项目功能需要去设计业务层.我们将会通过几种可能的业务层设计模式去分析,分析每种设计模式的优 ...
领域驱动系列：三种领域逻辑组织模式的本质
企业应用架构模式中明确提出了三种领域逻辑组织模式:事务脚本.领域模型和表模块.不少人看的云里雾里的,不少人说的似懂非懂的,主要原因是没有从项目的级别的分析和设计经验,只有单个项目模块的开发经验的人很难 ...
企业应用架构模式笔记
1 企业应用模式概述 1.1 企业应用的模式企业应用领域要解决的问题在某些方面要比做一个工具软件.或者一个电信通信软件等复杂的得多,比如纷杂的企业数据,各具特色的业务规则,变化莫测的用户需求.因此企 ...
[201004][企业应用架构模式][王怀民][周斌][译]
[201004][企业应用架构模式][王怀民][周斌][译] 模式列表引言 0.1 架构 0.2 企业应用 0.3 企业应用的种类 0.4 关于性能的考虑 0.5 模式 0.5.1 模式的结构 0. ...
企业应用架构模式学习笔记
1.概述 2.分层表现逻辑处理用户与软件间的交互.表现层的主要职责是向用户显示信息并把从用户那里获取的信息解释成领域层或数据源层上的各种动作. 数据源逻辑主要关注与其他系统的交互,这些系统将代表应用 ...
软件开发大师谈企业应用架构模式
<企业应用架构模式(英文版)> --作者:Martin Fowler 多年来,Martin Fowler --这位享誉世界的软件开发大师--见证了许多企业级应用项目.这些项目通常都包含相似 ...
企业应用架构模式-30天阅读计划
构建计算机系统并非易事.随着系统复杂性的增大,构建相应软件的难度将呈指数增大. 同其他行业一样,我们只有在不断的学习中进步,从成功经验中学习,从失败教训中学习,才有望克服这些困难. 这本书的内容就是这 ...
《企业应用架构模式》30天阅读计划
构建计算机系统并非易事.随着系统复杂性的增大,构建相应软件的难度将呈指数增大. 同其他行业一样,我们只有在不断的学习中进步,从成功经验中学习,从失败教训中学习,才有望克服这些困难. 这本书的内容就是这 ...
以太网的分层架构_读《企业应用架构模式》记录-分层
复杂软件系统中,分层理念使用最多,具体例子: 软件体系中, 从包含了操作系统调用的程序设计语言到设备驱动程序和CPU指令集再到芯片内部的各种逻辑门:网络互联中,FTP层架构在TCP上,TCP架构在IP ...

9.企业应用架构模式 --- 领域逻辑模式

9.企业应用架构模式 --- 领域逻辑模式相关推荐

最新文章

热门文章