概念中的DDD

前端之家收集整理的这篇文章主要介绍了概念中的DDD前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

概念中的DDD

DDD: 领域驱动设计,它是对面向对象的的分析和设计(OOAD,Object Orient Analysis Design)的一个补充,对技术框架进行了分层规划,同时对每个类进行了策略和类型划分。领域模型是领域驱动的核心 ,采用DDD的设计思想,业务逻辑不再集中在几个大型的类上,而是在大量相对小的领域对象上,这些类具有自己的状态和行为,每个类都是完成的独立的,并与现实领域的业务对象形成一种映射。基于DDD的架构设计,保证了系统的可维护性,扩展性和敏捷性,在处理复杂业务逻辑方面有着明显的优势!

编程世界观的改变

以下信息是从http://www.jdon.com/ddd.html上拷贝的,写的很好,这确实是一种编程世界观的改变,而传传统编程观念完全不同

过去需求分析和系统设计都是分离的,正如我们国家“系统分析师” 和“系统设计师” 两种职称考试一样,这样割裂的结果导致,需求分析的结果无法直接进行设计编程,而能够进行编程运行的代码扭曲需求,导致客户运行软件后才发现很多功能不是自己想要的,而且软件不能快速跟随需求变化

  DDD则打破了这种隔阂,提出了领域模型概念,统一了分析和设计编程,使得软件能够更灵活快速跟随需求变化。

  DDD革命性在于:领域模型准确反映了业务语言,而传统的分层架构只关心数据, 这些数据对象除了简单读、写操作外,没有任何业务方法,被比喻成失血模型,那么领域模型这种带有业务方法的充血模型到底好在哪里?

看到领域模型代码,就看到业务需求,没有翻译没有转换,保证软件真正实现“拷贝不走样”。

DDD最大的好处是:接触到需求第一步就是考虑领域模型,而不是将其切割成数据和行为,然后数据用数据库实现,行为使用服务实现,最后造成需求的首肢分离。DDD让你首先考虑的是业务语言,而不是数据。重点不同导致编程世界观不同。

DDD的特点

  • 分层架构
  1. 成熟,清晰的分层架构
  2. 领域对象与世界的业务映射
  3. 明确的职责划分
  • 复用性
  1. 领域对象是核心
  2. 领域对象复用:完整的业务对象描述
  3. 设计利用:设计基于领域对象而非基于数据库
  • 适用场合
  1. 具备复杂业务逻辑的软件开发
  2. 对设计和开发人员要求较高
  3. 不适合普通的CURD操作
  4. 系统的维护性与扩展性较高

对于DDD系统架构的分层

不使用DDD思想进行系统设计时,一般会分为3层,如数据层,业务层和表现层,而使用DDD这后,分层的方式发生了一些改变,先来看一下

  1. 表现层:也叫WEB层,UI层,一般体现出来的是页面的布局,可以用web mvc,web form,win form等去实现
  2. 应用层:用来协调应用活动,它不包含业务逻辑,它不保留业务对象的状态,但它保存应用任务的进度状态
  3. 领域层:包含领域信息,这是业务软件的核心,它保留业务对象的状态,对业务对象和它们状态的持久化工作委托给基础设施层
  4. 基础设施层:是其它层的基础,实现对业务对象的持久化,还对WEB层可以引用本层

DDD中的几个核心对象

Entities:这不是简单的poco实体,而是具备了业务逻辑的实体

Factories:工厂类,用来生产对象

Respositories:持久化,它本身就是DAO (Data Access Objects) 数据访问对象

Services:服务层,为上层提供了操作的接口,负责对象领域对象进行调试和封装,同时提供了各种形式的服务 

原文链接:https://www.f2er.com/javaschema/284835.html

猜你在找的设计模式相关文章