26、优惠及款项信息计算订单的总折扣率和折后总房价；分析业务约束 ， 第一个业务约束很明显不属于订单实体及其他相关实体的职责 ， 由销售管理应用服务委托系统参数设置应用服务进行判断 ， 当可对客户信息进行修改时 ， 还需要委托客户管理应用服务提供修改服务；房间是否可售需要根据房间状态决定 ， 这职责明显是由房间实体负责；已组合的基础房间是否可售 ， 由系统参数设置决定 ， 所以应该由销售管理应用服务委托系统参数设置应用服务进行判断 ， 至于房间是否已经被组合 ， 这是房间实体本身的职责；可否使用房间历史价格 ， 由销售管理应用服务委托系统参数设置应用服务进行判断；对于解筹操作 ， 订单实体包含认筹登记记录 ， 因此应该由订单负责；订单的总折扣率和 。

27、折后总房价是由订单的各种优惠及款项信息决定的 ， 因此属于订单的职责 ， 但进一步分析 ， 总折扣率和折后总房价可能由不同的计算方式 ， 因此 ， 应该设计一个订单总折扣率和折后总房价计算器实体 ， 并由订单委托其进行计算 ， 综上所述 ， 得出如下时序图：5.1.15 客户下订单时序图这个时序图的设计并不是最终的客户下订单用例的时序图 ， 它主要表达了一个复杂的业务 ， 需要通过合理的抽象以及对业务变化的预见性 ， 建立好合理的模型 ， 并把职责合理的划分到不同的服务或领域对象中 ， 从而得到更好的灵活性或扩展性 ， 这也是领域驱动设计的核心思想 。
5.1.2 对象的查询业务、报表业务分析：对象的查询业务、报表业务同样也是系统的典型操作 ， 与对象的增 。

28、、删、改不同 ， 对象的查询业务、报表业务的共同特征是：1）这些操作不会改变业务实体的状态和数据；2）这些操作返回的数据量可能比较大；3）这些操作查询的结果很多时候是跨领域对象的数据视图；4）这些操作通常比较频繁；5）这些操作不需要调用领域对象的具有业务意义的方法 。
基于这些特征 ， 如果使用“充血模型”设计方法 ， 就会出现一系列问题 ， 下面以基础房间的查询作为例子来说明问题：基础房间查询只需要返回一个符合查询条件的基础房间视图列表 ， 它包括的数据除了基础房间的基本信息外 ， 还包括基础房间的楼栋名、分期名、楼盘名、朝向、景观、开发商名等关联信息 ， 如果直接获取领域对象再转换成数据传输对象 ， 由于领域对象仓库实现使用 。

29、了ORM框架 ， 返回的都是对象 ， 那么 ， 每个房间领域对象必须要返回其相关联的所有对象：图表 5.1.21 基础房间关联对象类图而事实上 ， 对于该查询业务来说 ， 它只需要这些关联对象中的某一个或几个属性（如：分期对象的分期名称） ， 可以看到 ， 使用加载领域对象的方式有下面的问题：l 加载了大量不必要的数据 ， 严重浪费磁盘IO资源 ， 可能会导致磁盘IO瓶颈；l 创建大量的关联对象 ， 并且需要进行对象关系转换 ， 浪费CPU资源；l 大量对象会导致内存开销大增 ， 在高并发时可能会导致内存溢出；l 加载的对象是领域对象 ， 但查询业务并不需要调用领域对象的任何业务方法；l 应用服务层需要把领域对象转化为DTO返回 ， 这同时浪费CP 。

30、U和内存资源 。
这一系列的问题说明 ， 对象查询业务、报表业务并不适合使用“充血模型”进行设计 。
决策：由于对象的查询业务、报表业务没有对业务实体的状态产生影响 ， 因此严格来说 ， 它们并不属于“业务” ， 我们可以以一种“查询通道”的方式来实现 ， 查询通道的意思是：不加载领域对象 ， 也不使用ORM ， 而是直接使用结构化查询语言SQL（对于不同的持久化实现机制 ， 有不同的结构化查询语言 ， 如XML的XQuery、XQL等） ， 通过组合查询直接返回数据视图所需要的数据 ， 并组装成一个DTO返回（注：这只是其中一种实现方案 ， 还有一种比较可行的实现方案是：为需要查询的数据在数据库建立数据视图 ， 然后通过ORM工具把视图映射为一个DT 。

31、O ， 这种方式就不需要直接编写SQL语句 ， 但返回的对象并不是DO ， 而是没有任何业务含义的DTO） ， 下图展示了查询通过的逻辑层关系图：图表 5.1.22 查询业务、报表业务设计决策图（查询通道、贫血模型）与“充血模型”不同 ， 应用服务层绕过了领域层 ， 直接通过查询通道查询数据 ， 并把查询结果直接以DTO的形式返回 ， 下面是使用查询通道查询数据的时序图：5.1.23 查询通道时序图这种方式 ， 免去了加载无用数据、对象关系映射、领域对象与DTO的转换逻辑 ， 从而大大的减轻了磁盘IO、CPU开销和内存开销 。

稿源：(未知)

【傻大方】网址：/a/2021/0902/0024073868.html

标题：SaaS|SaaS RES营销管理系统架构设计( 五 )