领域驱动设计(DDD:Domain-Driven Design)

转自Jdon.com,DDD专题戳这里开始

Eric Evans的“Domain-Driven Design领域驱动设计”简称DDD,Evans DDD是一套综合软件系统分析和设计的面向对象建模方法

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

  DDD则打破了这种隔阂,提出了领域模型概念,统一了分析和设计编程,使得软件能够更灵活快速跟随需求变化。见下面DDD与传统CRUD或过程脚本或者面向数据表等在开发效率上比较:

  服务器后端发展三个阶段:

  1. UI+DataBase的两层架构,这种面向数据库的架构(上图table module )没有灵活性。
  2. UI+Service+DataBase的多层SOA架构,这种服务+表模型的架构易使服务变得囊肿,难于维护拓展,伸缩性能差,见这里讨论或Spring Web 应用的最大败笔.
  3. DDD+SOA的事件驱动的CQRS读写分离架构,应付复杂业务逻辑,以聚合模型替代数据表模型,以并发的事件驱动替代串联的消息驱动。真正实现以业务实体为核心的灵活拓展。

  DDD革命性在于:领域模型准确反映了业务语言,而传统J2EE或Spring+Hibernate等事务性编程模型只关心数据,这些数据对象除了简单setter/getter方法外,没有任何业务方法,被比喻成失血模型,那么领域模型这种带有业务方法的充血模型到底好在哪里?

  以比赛Match为案例,比赛有“开始”和“结束”等业务行为,但是传统经典的方式是将“开始”和“结束”行为放在比赛的服务Service中,而不是放在比赛对象本身之中。我们不能因为用了计算机,用了数据库,用了框架,业务模型反而被技术框架给绑架,就像人虽然是由母亲生的,但是人的吃喝拉撒母亲不能替代,更不能以母爱名义肢解人的正常职责行为,如果是这样,这个人就是被母爱绑架了。

  提倡充血模型,实际就是让过去被肢解被黑crack的业务模型回归正常,当然这也会被一些先入为主或被洗过脑的程序员看成反而不正常,这更是极大可悲之处。看到领域模型代码,就看到业务需求,没有翻译没有转换,保证软件真正实现“拷贝不走样”。

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

  DDD是解决复杂中大型软件的一套行之有效方式,在国外已经成为主流。DDD认为很多原因造成软件的复杂性,我们不可能避免这些复杂性,能做的是对复杂的问题进行控制。而一个好的领域模型是控制复杂问题的关键。领域模型的价值在于提供一种通用的语言,使得领域专家和软件技术人员联系在一起,沟通无歧义。

  DDD在软件生产流程中定位i如下图,DDD落地实现离不开in-memory缓存、 CQRS、 DCI、 EDA或Event Source几大大相关领域。

  DDD基础:面向对象专题

  2012年Eric Evans关于技术如何影响DDD的会话

  聚合与一致性和有界上下文

 

教程与文章

面向对象建模与数据库建模两种分析设计方法的比较
数据库驱动设计与对象建模是决定软件不同命运的两大派别,谁可以让软件更具有生命,维护拓展更方便?伸缩性更强?

对象和关系数据库的天然阻抗
软件是讲究方法的,要谈方法,这个世界只有两种:一是将复杂问题简单化的方法;另一是将简单问题复杂化的方法。对于软件这个领域,你只能选择前者。

面向对象与领域建模 
据调查,目前有70%左右程序员是在使用OO语言编写传统过程化软件,缺乏完整的面向对象思维方法的教育和培训是基本根源,本文对软件开发中几个常见问题提出了独立的见解及尖锐的观点

Evans DDD 领域建模
如何提炼模型,而不是数据表,进而精化模型对象,使其能够反映领域概念基本本质是一个复杂过程,Evans DDD是2004年提出的具备革命性影响的软件思想。

实战DDD(Evans DDD:Domain-Driven Design领域驱动设计)
领域建模是一种艺术的技术,不是数学的技术,它是用来解决复杂软件快速应付变化的解决之道。

领域模型驱动设计(Evans DDD)之模型提炼

软件建模设计

状态对象:数据库的替代者
实体是一个有状态的对象,这是一个实战中非常重要但是容易被忽视的概念。

如何从职 责和协作中发现丰富对象?
给出了DDD具体实践中一些具体细节,是和DDD配合一起进行面向对象分析设计的好方法。

业务模型统一描述
统一语言是DDD一个重要特征和重点。 

DCI架构是什么? 
DCI架构:DCI: 对象的Data数据, 对象使用的Context场景, 对象的Interaction交互行为

Domain Events异步应用 
领域驱动设计和异步架构完美实战解决之道。

DDD DCI和领域事件
将DDD DCI Event sourcing结合在一个案例中,展示OOA和OOD实现过程,直至可运行的源代码。

业务建模:CQRS应用场景  
如何更好地在实践中实现DDD,又防止技术架构对业务领域的侵害,本文讨论引入CQRS使用场景。

DSM:Domain-Specific Modeling
DSM是超越UML/MDA一种新的建模方法,它成倍提高软件开发效率。

四色原型
我们在一个软件革命的开始,它象90年代我们看到的面向对象编程从传统过程语言中抽象出来一样。 如果说GOF设计模式开辟了OO对象设计新时代,那么原型模式和MDA将开辟后十年的软件新时代。更多四色专题

Feature-Driven Development特征驱动开发
使用JdonFramework等现代Model/Service框架是在什么项目工程背景下进行的?不是以前的XP(Extreme Programming )或RUP,而是FDD。

UML和Java的阻抗
如果Java和UML这种发展概念不匹配下去,我们真的要问UML过时了吗?

状态对象:数据库的替代者
这是一个实战中非常重要但是容易被忽视的概念,说它重要,是因为它比数据库重要;说它容易被忽视也是同样的原因,它经常被数据库概念替代。

不变性immutablity设计 
不变性是统领业务分析和高性能架构重要法门,通过业务上不变性分析设计,可以实现代码运行的并发高性能和高扩展性  

领域模型的隔离

行为驱动开发(BDD)如何与领域驱动设计(DDD)结合?
BDD认为是在不断敏捷迭代开发中从用户故事中挖掘领域模型,这种敏捷开发方式是否与DDD矛盾呢?

事件、契约设计与BDD
板桥banq提出中西结合的统一语言:场景 事件和状态,该文进行了论证。

DDD CQRS和Event Sourcing的案例:足球比赛
DDD + CQRS + Event Sourcing实现案例,结合代码与理论讲解。

集装箱车队系统的DDD案例
为上海某大型港口公司的运输系统实施的一个领域驱动设计DDD的实战咨询案例。

领域驱动设计企业线下培训与咨询

 

相关参考

为什么计算科学中最难的两件事是命名和缓存失效

Martin Fowler推荐的领域模型in-memory架构:LMAX架构

开源框架JdoFramework模型驱动快速开发

内存领域对象+事件驱动 = 量身定制的高并发架构

Spring 和 AspectJ实现领域驱动设计

领域驱动设计之我见

DDD实体

DDD值对象

DDD仓储Repository模式

DDD Specification规格模式

DDD服务

DDD聚合

领域事件

CQRS架构

职责驱动设计

更多 DDD领域驱动设计 有关领域建模经验探讨...

面向对象OOA OOD专题

敏捷工程方法

你可能感兴趣的:(架构设计)