1 引言
DDD,全名:Domain Driven Design,中文名:领域驱动设计。
2 DDD的分层
分层的架构方式是我们常用的,这里的分层是说n-layer,指的是逻辑的分层,目的是分离职责。常用的是三层:表现层,业务逻辑层,数据访问层。
DDD把原来经典三层(表现层,业务逻辑层,数据访问层)中的业务逻辑层又细分为两层:应用层和领域层。应用层负责领域对象的协调和调度,领域层包含具体的领域对象,领域规则(也就是业务规则),更大限度的实现业务规则的重用和职责的分离。将数据访问层并入基础架构层。变成了四层:
- Presentation
- Application
- Domain
- Infrastructure。
3 DDD的持久化设计
3.1 三层中的持久化设计
三层模式中的数据持久化是由数据访问层负责的,是至下而上的服务。为什么说是至下而上的呢?因为我们会写下面的代码。
public class Product
{
public Guid Id { get; set; }
public string Name { get; set; }
public List<Parameter> Parameters { get; set; }
public List<Delivery> Deliverys { get; set; }
public List<Image> Images { get; set; }
}
public class Parameter
{
}
public class Delivery
{ }
public class Image
{ }
public class ProductDAL
{
public bool Add(Product product);
public bool Update(Product product);
public bool Delete(Product product);
public Product Get(Guid id);
public List<Product> FindAll();
}
在数据访问层会写上所有针对这个Product的操作,不管需要与否,有时候干脆每张表一个DAL,用工具生成实体和数据访问类,这下数据访问层就完成了,后面可能会根据需要进行修改。管它业务层是否需要呢,反正需要的我都有了,不需要的我也有了,自己组合吧。
这种情况会造成代码浪费,甚至是大量的数据访问代码根本就没有用过。最重要的是也没有根据上层的需求来完成持久化的任务,而是简单的完成了表的增删改查,反正实现业务你就组合吧。总有一种组合会实现你的业务。这也就怪不得别人叫我们增删改查程序员了,因为如果业务简单,正好大部分业务都很简单,那么业务层就就剩下
new ProductDAL().Add(new Product());
这么一句了。
3.2 DDD的持久化设计
在DDD中,持久化被放在了基础架构层中。基础架构层不仅包括数据持久化,而且包括基础类库,Cross-Cutting等工具。DDD的持久化是至上而下的,是根据DDD的需要进行持久化。持久化的对象也变成了领域对象,而不再是单个表对象。
在领域层定义持久化的接口,持久化的对象是业务对象或者领域对象。在基础架构层实现领域层需要的持久化接口,具体的实现将领域对象持久化到数据存储中,是数据库还是文件,还是其他什么储存设备。一个领域对象是存储在一张表还是分开几张表,甚至是分开几个数据库,都是由基础架构层中的持久化模块来决定的,对领域层屏蔽实现的细节。只是在领域层需要持久化,或者需要反持久化的时候提供领域层需要的对象即可。
4 聚合
在进行面向对象设计的时候,我们会将一些对象进行组合,组合成为新的对象。随着系统的复杂,很容易造成对象的关系也复杂起来,对象的关系真的变成了错综负责的网状。
DDD提出的聚合可以解决这个问题,用来减少对象之间的关联关系。有聚合就有聚合根的概念,要不然就没有终点,还是会变成网状。我理解的聚合根,就是一个聚合的终点。聚合也可以理解为一系列对象,他们的关系好像树形,需要一个根节点来表达这一系列的对象。
4.1 如何发现聚合
那么如何来发现一个聚合呢?通过下面的一个小例子,我们来说明一下。
比如我们的场景是一个电子商务网站,需要定义一个商品类,商品肯定会有参数,图片,配送地域这些附属信息。我们一般会定义下面的类结构
public class Product
{
public Guid Id { get; set; }
public string Name { get; set; }
public List<Parameter> Parameters { get; set; }
public List<Delivery> Deliverys { get; set; }
public List<Image> Images { get; set; }
}
public class Parameter
{
}
public class Delivery
{ }
public class Image
{ }
其实这时候Product,Parameter,Delivery,Image就是一个聚合,Product就是这个聚合的根。因为Parameter,Delivery,Image这些概念脱离了Product是没有意义的,他们都是一个商品的附属信息,单独的谈论一张图片和一个参数没有任何意义。应该是从一个Product出发,然后引出来这个Product的参数,配送,图片,这样才比较合理。所以他们几个概念是一个聚合。
结束
今天我们就理解到这里,明后天我们再继续!!!
Technorati 标签:
DDD,
Aggregate
分享到:
相关推荐
不同于其它的架构方法,领域驱动设计DDD(DomainDrivenDesign)提出了从业务设计到代码实现一致性的要求,不再对分析模型和实现模型进行区分。也就是说从代码的结构中我们可以直接理解业务的设计,命名得当的话,非...
在一个实际复杂业务中落地DDD方法与相关架构 DDD促进传统架构微服务转型 DDD的为与不为 DDD实践中的那些坑 DDD在旅游电商架构演进中的实践 Every Entity as A Microservice Praise for Implementing Domain-Driven ...
分享我对领域驱动设计(DDD)的学习成果 化繁为简--DDD驱动复杂业务软件架构的演进 基于DDD的领域建模中的模版和工具实践 基于FP的DDD实践分享 架构分层模型适配 金融支付系统的改造之路 可视化的遗留系统微服务改造 ...
DDD领域驱动设计&中台实践资料合集,共20份。 DDD促进传统架构微服务...在一个实际复杂业务中落地DDD方法与相关架构 DDD的为与不为 DDD实践中的那些坑 DDD在旅游电商架构演进中的实践 Every Entity as A Microservice
JAVA,DDD领域设置模型,JAVA案例源码,让你1秒就懂DDD。
在一个实际复杂业务中落地DDD方法与相关架构(31页).pdf 基于 FP 的 DDD 实践(42页).pdf 基于DDD的领域建模中的模版和工具实践(36页).pdf 如何让DDD落地(32页).pdf 微服务的容器化实践(19页).pdf 架构分层...
一个非常好的文档来介绍DDD分层架构参考代码目录结构,接口层,应用层,领域层和基础层等!
P11 DDD实践——不同侧重点的DDD总结 课程特点: 大白话讲解领域驱动设计的晦涩词汇,手把手学习战略设计和战术设计,并配合实际项目进行开发落地实战,包括四层架构、洋葱架构、六边形架构、整洁架构等讲解。
DDD 领域驱动 简单的项目设计
ddd理解
2018年12月初,领域驱动设计峰会将再次在北京国际会议...2018年的领域驱动设计峰会是一次对国内DDD实践的检阅和展望,和业界同行一起探索DDD,同时我们也希望在软件行业可以更大范围和更深层次的展开实践的道路与前景
《实现领域驱动设计》分别从战略和战术层面详尽地讨论了如何实现DDD,其中包含了大量的最佳实践、设计准则和对一些问题的折中性讨论。《实现领域驱动设计》共分为14 章,在DDD 战略部分,《实现领域驱动设计》向...
DDD 领域驱动设计
下面我从领域、问题域、领域模型、设计、驱动这几个词语的含义和联系的角度去阐述DDD是如何融入到我们平时的软件开发初期阶段的。要理解什么是领域驱动设计,首先要理解什么是领域,什么是设计,还有驱动是什么意思...
领域驱动设计DDD 嘉禾培训教材领域驱动设计DDD 嘉禾培训教材
DDD对架构师培养的正面影响
图形数据显示功能(Graphical Data Display)是创建该调试器的初衷之一,能够显示各种数据结构之间的关系,并由此将数据结构以图形化形式显示;具有GDB/DBX/XDB的命令行界面,包括完全的文本编辑、历史纪录、搜寻...
DDD领域建模培训文档,很不错,欢迎大家下载,快来啊!
DDD领域驱动设计
DDD领域驱动设计和中台实践资料合集