领域驱动设计(DDD:Domain-Driven Design)过去系统分析和系统设计都是分离的,正如我们国家“系统分析师” 和“系统设计师” 两种职称考试一样,这样割裂的结果导致,需求分析的结果无法直接进行设计编程,而能够进行编程运行的代码却扭曲需求,导致客户运行软件后才发现很多功能不是自己想要的,而且软件不能快速跟随需求变化。 DDD则打破了这种隔阂,提出了领域模型概念,统一了分析和设计编程,使得软件能够更灵活快速跟随需求变化。见下面DDD与传统CRUD或过程脚本或者面向数据表等在开发效率上比较: 服务器后端发展三个阶段:
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的会话聚合与一致性和有界上下文
教程与文章
相关参考为什么计算科学中最难的两件事是命名和缓存失效Martin Fowler推荐的领域模型in-memory架构:LMAX架构开源框架JdoFramework模型驱动快速开发内存领域对象+事件驱动 = 量身定制的高并发架构Spring 和 AspectJ实现领域驱动设计领域驱动设计之我见DDD实体DDD值对象DDD仓储Repository模式DDD Specification规格模式DDD服务DDD聚合领域事件CQRS架构职责驱动设计更多 DDD领域驱动设计 有关领域建模经验探讨...面向对象OOA OOD专题敏捷工程方法树的生老病死 空间是在变换的、时间是在流逝的(时间 = 空间的变化)。整个世界是在发展变化的。是否理解这个世界,关键在于是否理解了“空间”和“时间”。当程序.... Spark比Hadoop并没有想象得那么快,以前号称快100倍,实际只快19%,这是 Making Sense of Performance in Data A.... 北京的中国人zxh0(微博:@我不是达芬奇鹰)使用Go语言编写了JVM项目 jvm.go 引起业界注意,著名网站infoworld给予了高度评价,认为虽然该项目.... Uber通过其在线调度平台能自动对乘客和车辆进行适配,大大提高了城市交通效率。其首席架构师Matt Ranney最近透露了其调度系统的概要,其系统是如何将乘客和.... Event Sourcing并不是存储状态,所有应用状态是代表事实的原始证据,它完全打开了我们应用的全新架构。 Why use Event Sourcing.... |
|
来自: codingparty > 《开发》