本文是我学习Scott Millett & Nick Tune编著的《领域驱动设计模式、原理与实践》一书的学习笔记,一共会分为4个部分以下,此文为第1部分:html
① 领域驱动设计的原则与实践数据库
② 战略模式:在有界上下文之间通讯设计模式
③ 战术模式:建立有效的领域模型架构
④ 有效应用程序的设计模式框架
脑图浏览:https://www.processon.com/view/5cb49b14e4b0a13c9de1042d#map微服务
这一章主要介绍了DDD是什么,强调DDD是一种开发思想体系,它是模式(战略模式、战术模式)、原则和实践的集合,能够被应用到软件设计中以管理复杂性。工具
DDD并不是一种模式语言,它是专一于交付的一种协做思想体系,其中通讯起核心做用,而要高效通讯,就须要使用公共语言。学习
DDD会将侧重点放在如下几个方面:网站
更为重要的是,不要认为DDD是一套框架,DDD也不是银弹或灵丹妙药,不可在项目中小题大作!编码
下图展现了一个演进的领域驱动设计过程:
From:张逸《领域驱动战略设计实践》课程
这里摘抄一段张逸老师在《领域驱动战略设计实践》课程中的话:
面对客户的业务需求,由领域专家与开发团队展开充分的交流,通过需求分析与知识提炼,以得到清晰的问题域。经过对问题域进行分析和建模,识别限界上下文,利用它划分相对独立的领域,再经过上下文映射创建它们之间的关系,辅以分层架构与六边形架构划分系统的逻辑边界与物理边界,界定领域与技术之间的界限。以后,进入战术设计阶段,深刻到限界上下文内对领域进行建模,并以领域模型指导程序设计与编码实现。若在实现过程当中,发现领域模型存在重复、错位或缺失时,再进而对已有模型进行重构,甚至从新划分限界上下文。
两个不一样阶段的设计目标是保持一致的,它们是一个连贯的过程,彼此之间又相互指导与规范,并最终保证一个有效的领域模型和一个富有表达力的实现同时演进。
脑图地址:https://www.processon.com/view/5cb5e474e4b0841b84327187#map
这一章主要介绍了什么是知识提炼,知识提炼是一个持续协做达成共识以建立有用模型的过程,而如何实践好这个过程,介绍了一些最佳实践:好比专一于最有意思的对话、从用例开始、提出有力的问题等等。
而对于不须要构建新模型的人来讲,研究现有模型也是有技巧的,我的感触最深的就是要真正理解意图,也就是不要盲从于客户的需求,由于这个需求极可能并不能真正地解决问题和创造价值,每每须要更深层次地理解隐含的愿景而且可以认识到业务到底试图达到什么。影响地图和业务模型是两个经典的实践方法,书中的例子在线运动装备运营商的业务模型图也比较经典。
脑图浏览地址:https://www.processon.com/view/5cba8957e4b059e20a0068c8#map
这一章主要介绍了核心领域,在一个大的问题空间中会同时存在不少的小问题域,而这些小问题域每每只有少部分是核心领域,其余的可能都是通用域和支撑域。核心域是咱们软件的根本竞争力所在,所以也能够说是咱们编写软件的缘由。拿一个在线拍卖网站来讲,能够见下图所示划分了核心域、支撑域和通用域:
对于核心域,咱们须要配备最好的开发人员专一于此。对于支撑域,咱们能够外包开发或者配备初级开发人员,可是要确保支撑域中的模型足够好。而对于通用域,若是能够,咱们能够寻求购买现成解决方案。
脑图浏览地址:https://www.processon.com/view/5cbaa844e4b01941c8b441d2
这一章主要介绍了模型驱动设计和通用语言的重要性,模型驱动设计是将分析模型(业务模型)绑定到代码实现模型并确保这两个模型保持协同并可用的过程。
模型驱动设计专一于实现以及对于初始模型可能须要修改的约束,领域驱动设计则专一于语言、协做和领域知识,他们是一个彼此互补的关系。而要实现协做,就须要使用通用语言,借助通用语言能够将分析模型和代码模型绑定在一块儿,并最终实现团队建模。实践UL是一个持续的过程,多个迭代后会不断对UL进行验证和改进,以便实现更好的协做。
因为时间和精力都有限,只有仅仅为核心域应用模型驱动设计和建立UL才能带来最大的价值,而不须要将这些实践应用到整个应用程序之中。
脑图浏览地址:https://www.processon.com/view/5cbab6c5e4b06bcc13844497
这一章主要介绍了领域层的概念及做用,下图展现领域层在在整个应用程序代码中的位置,领域层的最大做用就在于隔离领域模型的复杂性和应用程序的技术复杂性。
在领域建模时能够遵循的设计模式,Martin Fowler在《企业应用架构模式》一书中提出了如下几种:
脑图浏览地址:https://www.processon.com/view/5cbad3dee4b09a3e45a3fbc6
一般状况下,尝试将单个模型用于复杂问题域一般会致使代码变成大泥球,并且会增长团队之间的协做成本并下降交付业务价值的效率。有界上下文就是划分和破除这种大模型的有效方式,一个有界上下文就是一个语言边界,它能够隔离模型以免领域术语在不一样上下文中的歧义。而咱们经常提到的微服务,我的感受更像是有界上下文的一种技术实现途径之一,有界上下文中具备较高的自主性,拥有从展示层、领域逻辑层再到持久化层的完整代码堆栈,正应对了咱们的每个微服务的应用程序,也具备较高的独立性,拥有本身的数据库和一套完成的垂直切片的架构模式。
书中还提到一个重要的观点,那就是“并不是全部有界上下文都共享相同的架构模式”,换句话说就是能够将不一样的架构模式应用到不一样的有界上下文中。想一想这年来的企业应用架构模式的发展,已经从单一的架构风格发展为了混合式的架构风格了,就微软的大DEMO项目eShopOnContainers而言,也具备多种架构风格(简单的数据驱动CRUD+简化的分层DDD等),以下图所示:
所以,咱们也不该该局限在某一种或者两种架构模式上,而是应该量身应用,没有复杂性业务逻辑的微服务,那就应该KISS(Keep It Simple & Stupid),不然就能够考虑DDD。
脑图浏览地址:https://www.processon.com/view/5cbc3240e4b0bab909613768
上下文映射用来捕获各个有界上下文之间的技术与组织关系,它最大的做用就是保持模型的完整性。张逸老师在《领域驱动战略设计实践》课程中提到,在战略设计阶段,针对问题域,经过引入限界上下文和上下文映射能够对问题域进行合理的分解,识别出核心领域和子领域,并肯定领域的边界以及他们之间的关系,从而维持模型的完整性。
限界上下文不只局限于对领域模型的控制,而在于分离关注点以后,使得整个上下文能够成为独立部署的设计单元,这就是咱们很是熟悉的“微服务”的概念;而上下文映射的诸多模式则对应了微服务之间的协做。
脑图浏览地址:https://www.processon.com/view/5cc1cbe4e4b0841b84400fc9
这一章讨论了应用程序架构、服务和客户端,惟一记住的只有一句:“DDD不须要特殊的架构,只要是能将技术问题与业务问题分离的架构便可”。
脑图浏览地址:https://www.processon.com/view/5cc46afbe4b08b66b9bd9513
DDD的战术模式虽然能够指导咱们建立有效领域模型,但这并不是DDD的真正价值所在。由于,DDD其实并不是编码这么简单,与领域专家的协做以进行知识提炼,以及在通用语言中表述的问题域达成共识才是DDD的支柱。
在现实中,团队在应用DDD时一般会低估应用DDD的成本,应用DDD须要一个愿意学习该领域的聪明专一的团队,还须要领域专家的参与,没有他们,团队就没法揭示更深层的看法。
脑图浏览地址:https://www.processon.com/view/5cc5568be4b059e20a0bc1e1
DDD不是灵丹妙药,更不是“银弹”,张逸老师说道:请事先下降对领域驱动设计的不合现实的指望,要学会运用设计原则去解决问题,而非所谓的“设计规范”。更为重要的是,仅仅在须要时应用DDD原则,不要将其用做解决全部问题的工具。
整体来讲,这一章比较高屋建瓴,总结性的内容偏多,但对于没有多少实战经验的人来讲,阅读完不会有太深入的印象。不过,这并不影响,后续就是战略设计和战术设计的部分了,相信会随着学习的深刻,再反过来看这些原则和实践会有更多的认识。
Scott Millett & Nick Tune,《领域驱动设计模式、原理与实践》
在同事的推荐下,开始学习张逸老师的《领域驱动战略设计实践》课程,配合《领域驱动设计模式、原理与实践》一书共同窗习DDD,感受会比单看书好不少,也在此推荐一下张逸老师的这门课,五月份立刻会出《领域驱动战术设计实践》,值得期待。
原文出处:https://www.cnblogs.com/edisonchou/p/edc_ddd_foundation_study_part1.html