领域驱动设计(DDD)技术分享

注:本文为技术讨论会上的内容要点摘录整理的,相关内容仅作参考。

1       “模型”的几个概念

下面这2个名词容易混淆:

Module---模块,通常按照功能来划分,比如按照业务功能来划分

Model --模型,它通常出现在下面几个概念中:

 

l  MVVM --Model+View+ViewModel

l  MVP  --Model+View+Presenter

l  MVC  --Model+View+Controller

 

所以常说的Model实际上包含了View Model,Domain Model(简称DM),Entity Model。

 

PS:上面说的MVVM,MVP,MVC都属于“表现层架构模式”。

 

2       Entity--实体模型

2.1     概念来源

Entity--实体,其实它是来自于数据库设计中的概念,通常完善的数据库设计过程包含下面3个阶段:

1,  概念模型设计---E-R,抽象层次最高

2,  实体模型设计---Entity

3,  物理模型设计----具体数据库系统上面的表、视图、存储过程设计

 

2.2     Entity和表架构的关系

2.2.1  映射的种类

Entity映射的种类,可以有

l  表,

l  视图,

l  存储过程,

l  甚至数据库函数。

 

MS EF 将自定义SQL语句映射成实体类?

2.2.2  自定义SQL语句

1,  不同于视图,不能在视图中设定查询参数,

2,  相当于是存储过程和视图的结合体。

 

2.2.3  多对多关系

Entity和表等是一个“多对多关系”。

原因?

如果直接映射全表的字段到Entity,相当于是执行

Select * form Table

查询,这种方式有损效率。

 

2.3     懒人效应

所有的ORM工具都只能作为“工具”,会促使“懒人效应”。

1,  从表反向生成实体类,导致不愿意根据业务需求灵活定义实体类。

2,  没有自定义的实体类,所以每次都使用“全表映射”的实体类。

 

因此导致我们用ORM框架做的项目查询效率没有手写SQL的项目高。

要解决这个问题,就得看ORM框架是否支持“按需查询”

 

PS:---Linq2Sql,MS EF,PDF.NET 就是这样的框架。

 

 

 

3       “数据”的变化

3.1     “持久化”概念:

数据的存储媒介:内存,磁盘等。由于内存的数据容易丢失,所以要写入磁盘等长久存储媒介,数据的这个处理过程就是持久化。

 

3.2     在各个模型层面的变化过程:

 

1,ViewModel--〉数据从DM到视图界面的过程;

2,Entity--〉数据从DM到数据库一个“持久化”过程。

 

ViewModel《--DM--》Entity

PS:有同学说这3个Model相互转换很麻烦,其实可以使用第三方工具来做,比如开源的AutoMapper。

 

传统三层:

UI--〉BLL--〉DAL

 

UI《-BLL〈--DAL

该模式的特点,是高度依赖于数据库设计,没有数据库无法开工。

 

 

4       DDD--领域驱动设计:

4.1     领域模型

DDD,着重强调:-领域模型

PS:以我们这次项目为原型做好的领域模型介绍。

 

4.2     DDD实践的关键步骤:

4.2.1  领域建模

 

UML是一种建模工具,画草图,文档,讨论组等。。。。

 

UML强调的主要功能是“沟通”,把UML工具作为沟通的重要工具。

 

4.2.2  聚合根

--领域下的所有的对象都从这个根对象衍生出来,那这个对象就是这个领域下面的聚合根

 

4.3     DDD分层

常见的方式按照约定,分为:

l  Presentation Layer--表现层,

l  Domain Layer--领域层,

l  Repository Layer--仓储层

 PS:Repository Layer不同于三层架构的DAL,其中最关键的就是“驱动方向”不同,在DDD中,是Domain Layer需要什麽,Repository Layer提供什麽;而在DAL中相反,不管BLL是否需要,先提供一堆DAL方法再说,没有“领域”的需求。

4.4     领域驱动开发模式的开发过程

1、分析业务需求。

2、设计领域对象模型

3、测试领域对象模型

4、设计业务处理类

5、设计Entity和ViewModel

6、测试业务处理类

7、设计表架构

8、开发用户界面

 

 

5       数据库查询最有损效率的地方

l  全表查询;

l  连表查询;

l  不合理的使用索引。

 

优化方式:

1,              避免全表查询;

2,              将常见的表数据缓存,化解连表查询为单表查询。

 

很多项目都是CRUD(增,删,改,查)。

 

 

6       附录

6.1     参考资源:

UML类图关系大全

http://www.cnblogs.com/riky/archive/2007/04/07/704298.html

 

 

“领域驱动开发”实例之旅(1)--不一样的开发模式

http://www.cnblogs.com/bluedoctor/archive/2011/06/24/2088392.html

 

 

使用View Model从表现层分离领域模型

http://www.cnblogs.com/shanyou/archive/2010/04/03/1703501.html



 

     本文转自深蓝医生博客园博客,原文链接:http://www.cnblogs.com/bluedoctor/archive/2012/12/07/2807036.html,如需转载请自行联系原作者


 

 

上一篇:iOS10新特性提升安全 连接WiFi弹出提醒


下一篇:[10.14 workshop] 自定义 Prometheus 监控指标并通过 Grafana 展示