第九天-《企业应用架构模式》-领域逻辑模式

pinecone 发布于2019-07-01 11:18 / 2756人阅读

摘要：领域模型应当使用细粒度的对象，这些对象应有细粒度的接口。它封装了应用的业务逻辑事务控制及其操作实现中的响应协调。

1. 事务脚本 1）调用数据库：

事务脚本将所有逻辑组成单个过程，在过程中直接调用数据库，或者只通过一个简单的数据库封存器。

2）脚本处理：

每个事务都有自己的事务脚本，尽管事务间的公共子任务可以被分解成多个子程序。

3）运行机制：

a.事务脚本应该置于与其他处理表现层和数据源层的类相独立的类中，把事务脚本组织成类的两种方法：

a. 将数个事务脚本放在一个类中，每个类围绕一个主题将相关的事务脚本组织在一起；

b. 使用Command模式，每一个事务脚本对应一个类 (command)

4）使用时机:

业务逻辑简单场景（同时注意谨慎提取公共子程序以减少代码冗余），当业务复杂时则需要建立领域模型

5）优点：

当问题本身是简单的时，使用事务脚本可以加快开发速度，而且运行更快

6）示例：

假如有如下需求：

数据库设计为：

其中，RevenueRecognition表引用Contract表的Id作为外键。根据需求和数据库设计，事务脚本类图设计为：

这里，Gateway为数据库访问封存器，RecognitionServices为事务脚本类。CalculateRevenueRecognitions方法用于计算并保存需入账信息（合同编号、时间、收费金额），RecognizedRevenue用于按照合同编号、指定日期查询已收费用。应用程序只需要分别单个调取这2个方法即可。

2. 领域模型 1）运行机制

领域模型与数据库模型的区别：领域模型混合数据和处理过程，拥有多值属性和复杂的关联网，并且使用继承、策略、设计模式，是一张由互联的细粒度对象组成的复杂网络；

使用领域逻辑的一个常见问题: 领域对象过于臃肿，可能会产生冗余代码

数据库映射：简单领域模型可以使用活动记录，而复杂领域模型需要使用数据映射器。

领域模型应当使用细粒度的对象，这些对象应有细粒度的接口。

2）使用时机

当业务规则复杂多变，涉及到校验、计算、衍生时。

数据库交互方式：首选数据映射器

3）示例：

对于上文中需求，设计类图如下：
　　　　

可以看到，这里收费方式使用了策略模式。

3. 表模块

表模块以一个类对应数据库中的一个表来组织领域逻辑，而且使用单一的类实例来包含将对数据进行的各种操作程序。

表模块与领域逻辑的区别：如果有多个订单，领域模型对每个订单都有一个对象，而表模块则只用一个对象来处理所有订单（表模块没有标识符来标出它所代表的实体对象）。

1）运行机制

长处：允许你将数据与行为封装在一起，同时有可以充分利用关系数据库的优点

2）使用时机

当使用记录集存取表数据时使用（表模块很大程度上依赖于以表方式组织的数据）
　　

3）示例：

设计类图如下：
　　
　　　　

4. 服务层

服务层定义了应用的边界和从接口客户层角度所能看到的可用操作集。它封装了应用的业务逻辑、事务控制及其操作实现中的响应协调。
　　

1）运行机制

业务逻辑分类：领域逻辑、应用逻辑

两种基本的实现方法：

领域外观方法：

服务层以领域模型之上的瘦外观集合方式实现（负责实现外观的类不包含任何业务逻辑，所有业务逻辑均由领域模型实现）

操作脚本方法：

服务层由一组相对复杂的类组成，这些类直接实现应用逻辑，但将领域逻辑委托给封装好的领域对象类

服务层接口时粗粒度的，必要时候可以远程调用（在服务层之上增加远程外观或者直接让服务层实现远程接口）
　　

2）使用时机 服务层优点：

它定义了一个公共的应用操作集合，这个集合可被各种客户使用，而且服务层在每个操作中都会协调应用的响应。

当业务逻辑有多种客户，或者用例响应中的多个事务性资源，则需要服务层

云服务器 GPU云服务器架构模式软件架构模式大数据架构模式数据库架构模式

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/30075.html

第十天-《企业应用架构模式》-数据源架构模式

摘要：运行机制表数据入口包含了用于访问单个表或试图的所有，如选择插入更新删除等。其他代码调用它的方法来实现所有与数据库的交互。示例如下图分别是普通情况下充分利用特征下的表数据入口实现行数据入口充当数据源中单条记录入口的对象，每行一个实例。 1. 表数据入口　　充当数据库表访问入口的对象，一个实例处理表中所有的行。 1）运行机制：　　　　表数据入口包含了用于访问单个表或试图的所有SQL，如...

Drummor 2019-07-01 11:18 评论0 收藏0
第二天-《企业应用架构模式》-组织领域逻辑

摘要：模型抉择领域逻辑复杂度抉择领域逻辑复杂度较低时，选择事物脚本如果开发环境拥有大量基于记录集的工具和，可以选择表模块开发小组经验丰富时，选择领域模型种模式并不互相排斥，可以同时使用服务层服务层是从领域层分离出来的，用于置于底层的领域模型或表模 1. 模型抉择： 1）领域逻辑复杂度：　　showImg(https://segmentfault.com/img/remote/1460000...

wwolf 2019-07-01 11:15 评论0 收藏0
第三天-《企业应用架构模式》-映射到关系数据库

摘要：如果数据非常类似，可把数据从内存方案中转化到逻辑数据存储方案，映射从逻辑数据存储方案到实际物理存储方案第二部包含区别使用元数据元数据映射基于把映射浓缩到元数据文件的方法。元数据文件详细描述数据库中列如何映射到对象的域。关系数据库之所以取得成功，最重要的原因之一就是SQL的存在，它是数据库通信标准语言。 1. 架构模式：驱动领域逻辑访问数据的方式： SQL语句嵌入在程序设计语言中； ...

chenatu 2019-07-01 11:15 评论0 收藏0
企业应用架构模式-30天阅读计划

摘要：企业应用在某些方面要比电信软件简单得多多线程问题没有那么困难，无需关注硬件设备与软件的集成。但是，在某些方面，企业应用又比电信软件复杂得多企业应用一般都涉及到大量复杂数据，而且必须处理很多不合逻辑的业务规则。构建计算机系统并非易事。随着系统复杂性的增大，构建相应软件的难度将呈指数增大。同其他行业一样，我们只有在不断的学习中进步，从成功经验中学习，从失败教训中学习，才有望克服这些困难...

null1145 2019-07-01 11:15 评论0 收藏0
一文读懂微服务架构的重构策略

摘要：相反，它由单体中的适配器和使用一个或多个进程间通信机制的服务组成。因为微服务架构的本质是一组围绕业务功能组织的松耦合服务。如果你尝试将此类功能实现为服务，则通常会发现，由于过多的进程间通信而导致性能下降。这是快速展示微服务架构价值的好方法。你很有可能正在处理大型复杂的单体应用程序，每天开发和部署应用程序的经历都很缓慢而且很痛苦。微服务看起来非常适合你的应用程序，但它也更像是一项遥不可及的必杀...

jaysun 2019-05-22 19:25 评论0 收藏0