.NET应用架构设计—面向查询的领域驱动设计实践(调整传统三层架构,外加维护型的业务开关)

阅读目录:

  • 1.背景介绍
  • 2.在业务层中加入核心领域模型(引入DomainModel,让逻辑、数据有家可归,变成一个完整的业务对象)
  • 3.统一协调层Application Layer(加入协调层来转换DomianModel)
  • 4.从数据扁平结构转换成OO体系结构(使用OO丰富代码结构)
  • 5.DomainModel中的内容(带开关的Specification、SOA化的Specification)
  • 6.模式、重构、单元测试在领域模型中的运用

1.背景介绍

由于时间关系废话不多扯了,直奔主题,对领域驱动设计不是太了解的朋友请先熟悉相关主题或参考本人以下两篇文章:

.NET领域驱动设计—初尝(疑问、模式、原则、工具、过程、框架、实践),这篇文章对领域驱动设计的基本精神详细分析; .NET领域驱动设计—实践(穿过迷雾走向光明) ,这篇文章对领域驱动设计的一个基本实践,记录下了实践过程、建模的技巧等内容;

DomainModel是由很多细粒度的Object组成,按照以往的教训(将Object行为、数据肢解,得到一个残缺的Object),现在我们将逻辑行为和数据绑定在一起,形成了一个丰富的领域模型,这也是面向对象设计原则之一;想了解更多关于实现面向对象的技巧请参考【《实现模式》作者:Kent Beck】一书;

但是这样又带来了由于充血型DDD模型会给面向大规模查询的业务模块带来一定的性能开销,试想一个OrderManager对象,如果我们需要获取在某个条件范围类的所有Order会给OrderManager带来很多性能、逻辑上的复杂度;根据DDD.CQRS架构,得知将DomainModel中的查询逻辑单独剥离出去,让Command端很干净的处理聚合的写逻辑,在Query端也很直接的处理查询逻辑;

这样设计之后会有一个很尴尬的情况,在Query端的DomainModel不被关注了,因为Query的逻辑有简单有复杂,大型站点会有很多复杂的查询逻辑还会有很多的业务开关,做过维护的朋友应该知道新功能上线需要有switch的控制,这是为了安全起见吧;但是简单的业务逻辑就会被我们下意识的认为不需要使用完整的DomainModel结构,还是使用传统的分层架构上层依赖下层,Business Layer直接依赖DataAccess Layer,其实这个时候Business Object已经不在是遵循“单一职责”原则了,这样时间一长又慢慢的回到了以前肢解Object的困境;

这篇文章是讲解如何在Query端实践DDD,如何运用DDD的强项来解决复杂业务逻辑的实现,尤其是复杂的业务逻辑需要开关控制的时候其实更需要DomainModel来完成;

2.在业务层中加入核心领域模型(引入DomainModel,让逻辑、数据有家可归,变成一个完整的业务对象)

由于我们缺乏领域模型,所以导致我们的业务逻辑、规则随波逐流,无家可归,时间久了就搞不清到底这块业务逻辑是哪里的;我们现有的Domain Model是一个数据映射对象用来传递数据用的,严格意义是一个DTO对象,大部分的项目都将DTO命名为DomainModel但是其实里面没有任何的行为、方法,只是一个纯粹的数据传输用的容器,所以称不上DomainModel;

所以我们首先要做的就是加入DomainModel,然后逐渐将逻辑搬移到DomainModel中来,在进行逐步的重构、单元测试,让其成为一个可以测试的具有一定核心价值的可重用的DomainModel;

3.统一协调层Application Layer(加入协调层来转换DomainModel)

我们的Service没有Application Layer  也称协调层,专门用来组装业务处理环节的统一调度中心,它并非只是一个简单的静态类;传统三层中没有应用层的概念或者说应用层的概念没扭曲了,或者并没有发挥其的核心作用;我们需要加入应用层来协调DomainModel的工作;

4.从数据扁平结构转换成OO体系结构(使用OO丰富代码结构)

当我们使用DTO对象成功将数据从数据源获取之后,就需要一个对象化的过程,将扁平化的数据实体转换成丰满的领域模型,这个时候所有的领域规则将起作用;

5.DomainModel中的内容(带开关的Specification、SOA化的Specification)

1.实体:

简单理解为OO对象,可以独立存在也可以聚合在某个领域实体下,如果聚合在某个实体下那么只能通过父级实体进行一系列的访问;

2.工厂:

对实体进行有相关约定的创建,这其中包括各种验证、约束、开关等等前提条件。注意:创建实体不像创建数据DTO那么简单;

3.规约、规约工厂:

对业务规则进行对象化,将原本淹没在杂乱无章代码中的核心业务规则提取出来统一管理;这可以很好的像规则配置化(专业称:规则外挂);注意:这可以和我们的业务开关进行合并;最值得惊喜的是可以通过规约工厂来实现面向SOA的规约;

4.领域事件(扩展):

监控、观察等等非侵入式的获取实体在业务处理当中的状态数据,如:发送一封邮件、记录一条LOG,但是这种代码严禁写入业务逻辑层包括分层架构中的任何一个层面,它必须是在一个无关紧要的宿主中进行,类似管道模型的Module;

5.面向特定业务开关:

由于我们每次添加或修改业务逻辑都会加入相应的开关控制,如果这个开关是和业务逻辑相关的那么就可以很巧妙的和规约合并设计;

6.模式、重构、单元测试在领域模型中的运用

设计模式的运用:通过运用DDD就可以方便的对Domain Model进行设计模式的强粒度运用;

重构的运用:对领域模型进行重构就不需要考虑业务逻辑会影响到其他层面;

单元测试的运用:可以独立对领域模型进行测试,包括细粒度的接口抽取都会很方便;

总结:由于时间关系文中都是精简的介绍,具体的理解可以参考我上传的代码示例:http://files.cnblogs.com/wangiqngpei557/3WDDDDemo.zip

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏CSDN技术头条

数据密集型系统架构设计

按照使用的资源类型划分,我们可以把系统分为三大类型:IO密集型、计算密集型,数据密集型。系统的类型反映了系统的主要瓶颈。现实情况中,大部分系统在由小变大的过程中...

24780
来自专栏蓝天

理解Load Average做好压力测试

SIP的第四期结束了,因为控制策略的丰富,早先的的压力测试结果已经无法反映在高并发和高压力下SIP的运行状况,因此需要重新作压力测试。跟在测试人员后面做了快一周...

8420
来自专栏云豹直播系统开发

短视频APP开发主要依赖于短视频SDK架构设计

短视频 SDK 架构中主要做的一些事情,这其中最重要的就是短视频 SDK 的架构设计,包括架构设计理念、架构图、整体数据流程、模块架构设计等。今天小编就简单介绍...

33830
来自专栏机器人网

收藏:自动化工程师教你如何完整做好一个项目

我们学PLC有时候是为了做项目,做项目需要做些什么步骤呢,学习什么知识点,看看老工程师怎么告诉你…… 一.做一个PLC项目的大体流程如下 ❶、熟悉好现场环境和...

28860
来自专栏Android 开发者

Android P 开发者预览版首发!

26120
来自专栏SDNLAB

网络可编程与验证

作者简介:唐昊,现就职于华为,从事云网络研发工作。本文所有观点仅代表作者个人观点,与作者现在或者之前所在的公司无关。

30520
来自专栏地方网络工作室的专栏

Vue2+VueRouter2+Webpack+Axios 构建项目实战2017重制版(一)基础知识概述

Vue2+VueRouter2+Webpack+Axios 构建项目实战2017重制版(一)基础知识概述 前言 2016年,我写了一系列的 VUE 入门教程,当...

24890
来自专栏沈唁志

详解Linux运维工程师必备技能

40020
来自专栏杨建荣的学习笔记

insert导致的性能问题大排查(r11笔记第26天)

今天开发的同学小窗口消息给我,向我咨询一个ORA错误的问题。 错误代码是ORA-30036,使用oerr ora 30036查看,由于是undo空间无法扩展导致...

357150
来自专栏13blog.site

Spring+SpringMVC+MyBatis+easyUI整合优化篇(八)代码优化整理小记及个人吐槽

前言 这两天也一直在纠结这一篇文章该写什么东西,前面临时加的两篇文章就有些打乱了整体节奏,这一篇又想去写一下代码层面优化的事情,可是也不太能抓住重要的点,不太确...

26460

扫码关注云+社区

领取腾讯云代金券