过去系统分析和系统设计都是分离的，正如我们国家“系统分析师” 和“系统设计师” 两种职称考试一样，这样割裂的结果导致，需求分析的结果无法直接进行设计编程，而能够进行编程运行的代码却扭曲需求，导致客户运行软件后才发现很多功能不是自己想要的，而且软件不能快速跟随需求变化
Eric Evans的“Domain-Driven Design领域驱动设计”简称DDD，Evans DDD是一套综合软件系统分析和设计的面向对象建模方法，本站Jdon.com是国内公开最早讨论DDD网站之一，可订阅DDD专题。初学者学习DDD可从研究本站Jdon框架的DDD应用源码开始，戳这里开始。
过去系统分析和系统设计都是分离的，正如我们国家“系统分析师” 和“系统设计师” 两种职称考试一样，这样割裂的结果导致，需求分析的结果无法直接进行设计编程，而能够进行编程运行的代码却扭曲需求，导致客户运行软件后才发现很多功能不是自己想要的，而且软件不能快速跟随需求变化。
DDD则打破了这种隔阂，提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。见下面DDD与传统CRUD或过程脚本或者面向数据表等在开发效率上比较：
服务器后端发展三个阶段：
DDD革命性在于：领域模型准确反映了业务语言，而传统J2EE或Spring+Hibernate等事务性编程模型只关心数据，这些数据对象除了简单setter/getter方法外，没有任何业务方法，被比喻成失血模型，那么领域模型这种带有业务方法的充血模型到底好在哪里？
以比赛Match为案例，比赛有“开始”和“结束”等业务行为，但是传统经典的方式是将“开始”和“结束”行为放在比赛的服务Service中，而不是放在比赛对象本身之中。我们不能因为用了计算机，用了数据库，用了框架，业务模型反而被技术框架给绑架，就像人虽然是由母亲生的，但是人的吃喝拉撒母亲不能替代，更不能以母爱名义肢解人的正常职责行为，如果是这样，这个人就是被母爱绑架了。
提倡充血模型，实际就是让过去被肢解被黑crack的业务模型回归正常，当然这也会被一些先入为主或被洗过脑的程序员看成反而不正常，这更是极大可悲之处。看到领域模型代码，就看到业务需求，没有翻译没有转换，保证软件真正实现“拷贝不走样”。
DDD最大的好处是：接触到需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。DDD让你首先考虑的是业务语言，而不是数据。重点不同导致编程世界观不同。
DDD是解决复杂中大型软件的一套行之有效方式，在国外已经成为主流。DDD认为很多原因造成软件的复杂性，我们不可能避免这些复杂性，能做的是对复杂的问题进行控制。而一个好的领域模型是控制复杂问题的关键。领域模型的价值在于提供一种通用的语言，使得领域专家、产品经理和软件技术人员联系在一起，沟通无歧义。
DDD落地实现离不开Clean架构、六边形架构、 CQRS、Event Source几大大相关领域。下图是传统以数据库为中心的架构与使用DDD实现以领域为中心架构的区别。
DDD专门为解决复杂性而诞生，因此解决思路完全不同于传统的CRUD，但是DDD本身掌握起来并不会感觉复杂，从程序员角度看，DDD其实是研究将包含业务逻辑的ifelse语句放在哪里的学问。
板桥大话DDD
用大白话简单谈谈DDD的一些基础特点，只是扫盲！数据库SQL强人慎入
业务代码编程陷阱案例 - jaxenter
非常普遍的不恰当的编程方式，失血模型导致的陷阱
面向对象建模与数据库建模两种分析设计方法的比较
数据库驱动设计与对象建模是决定软件不同命运的两大派别，谁可以让软件更具有生命，维护拓展更方便？伸缩性更强?
对象和关系数据库的天然阻抗
软件是讲究方法的，要谈方法，这个世界只有两种：一是将复杂问题简单化的方法；另一是将简单问题复杂化的方法。对于软件这个领域，你只能选择前者。
面向对象与领域建模
据调查，目前有70%左右程序员是在使用OO语言编写传统过程化软件，缺乏完整的面向对象思维方法的教育和培训是基本根源，本文对软件开发中几个常见问题提出了独立的见解及尖锐的观点
Evans DDD 领域建模
如何提炼模型，而不是数据表，进而精化模型对象，使其能够反映领域概念基本本质是一个复杂过程，Evans DDD是2004年提出的具备革命性影响的软件思想。
实战DDD(Evans DDD:Domain-Driven Design领域驱动设计)
领域建模是一种艺术的技术，不是数学的技术，它是用来解决复杂软件快速应付变化的解决之道。
如何从职责和协作中发现丰富的充血对象？
失血模型贫血模型是DDD最大敌人，如何根据SOLID原则和GRASP原则设计业务行为？本文给出了DDD具体实践中一些具体细节，是和DDD配合一起进行面向对象分析设计的好方法。
业务模型统一描述
统一语言是DDD一个重要特征和重点。
Domain Events异步应用
领域驱动设计和异步架构完美实战解决之道。
DDD DCI和领域事件
将DDD DCI Event sourcing结合在一个案例中，展示OOA和OOD实现过程，直至可运行的源代码。
业务建模：CQRS应用场景
如何更好地在实践中实现DDD，又防止技术架构对业务领域的侵害，本文讨论引入CQRS使用场景。
不变性immutablity设计
不变性是统领业务分析和高性能架构重要法门，通过业务上不变性分析设计，可以实现代码运行的并发高性能和高扩展性
事件、契约设计与BDD
板桥banq提出中西结合的统一语言：场景 事件和状态，该文进行了论证。
DDD CQRS和Event Sourcing的案例：足球比赛
DDD + CQRS + Event Sourcing实现案例，结合代码与理论讲解。
集装箱车队系统的DDD案例
为上海某大型港口公司的运输系统实施的一个领域驱动设计DDD的实战咨询案例。
向领域驱动设计前进： 如何使用DDD实现从单体到微服务迁移打造业务平台或中台？,
Eric Evans的“Domain-Driven Design领域驱动设计”简称DDD，Evans DDD是一套综合软件系统分析和设计的面向对象建模方法，本站Jdon.com是国内公开最早讨论DDD网站之一，可订阅DDD专题。初学者学习DDD可从研究本站Jdon框架的DDD应用源码开始，戳这里开始。
过去系统分析和系统设计都是分离的，正如我们国家“系统分析师” 和“系统设计师” 两种职称考试一样，这样割裂的结果导致，需求分析的结果无法直接进行设计编程，而能够进行编程运行的代码却扭曲需求，导致客户运行软件后才发现很多功能不是自己想要的，而且软件不能快速跟随需求变化。
DDD则打破了这种隔阂，提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。见下面DDD与传统CRUD或过程脚本或者面向数据表等在开发效率上比较：
服务器后端发展三个阶段：
DDD革命性在于：领域模型准确反映了业务语言，而传统J2EE或Spring+Hibernate等事务性编程模型只关心数据，这些数据对象除了简单setter/getter方法外，没有任何业务方法，被比喻成失血模型，那么领域模型这种带有业务方法的充血模型到底好在哪里？
以比赛Match为案例，比赛有“开始”和“结束”等业务行为，但是传统经典的方式是将“开始”和“结束”行为放在比赛的服务Service中，而不是放在比赛对象本身之中。我们不能因为用了计算机，用了数据库，用了框架，业务模型反而被技术框架给绑架，就像人虽然是由母亲生的，但是人的吃喝拉撒母亲不能替代，更不能以母爱名义肢解人的正常职责行为，如果是这样，这个人就是被母爱绑架了。
提倡充血模型，实际就是让过去被肢解被黑crack的业务模型回归正常，当然这也会被一些先入为主或被洗过脑的程序员看成反而不正常，这更是极大可悲之处。看到领域模型代码，就看到业务需求，没有翻译没有转换，保证软件真正实现“拷贝不走样”。
DDD最大的好处是：接触到需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。DDD让你首先考虑的是业务语言，而不是数据。重点不同导致编程世界观不同。
DDD是解决复杂中大型软件的一套行之有效方式，在国外已经成为主流。DDD认为很多原因造成软件的复杂性，我们不可能避免这些复杂性，能做的是对复杂的问题进行控制。而一个好的领域模型是控制复杂问题的关键。领域模型的价值在于提供一种通用的语言，使得领域专家、产品经理和软件技术人员联系在一起，沟通无歧义。
DDD落地实现离不开Clean架构、六边形架构、 CQRS、Event Source几大大相关领域。下图是传统以数据库为中心的架构与使用DDD实现以领域为中心架构的区别。
DDD专门为解决复杂性而诞生，因此解决思路完全不同于传统的CRUD，但是DDD本身掌握起来并不会感觉复杂，从程序员角度看，DDD其实是研究将包含业务逻辑的ifelse语句放在哪里的学问。
板桥大话DDD
用大白话简单谈谈DDD的一些基础特点，只是扫盲！数据库SQL强人慎入
业务代码编程陷阱案例 - jaxenter
非常普遍的不恰当的编程方式，失血模型导致的陷阱
类与数据结构的比较！每个优秀的软件设计师和架构师都需要牢记的问题
面向对象建模与数据库建模两种分析设计方法的比较
数据库驱动设计与对象建模是决定软件不同命运的两大派别，谁可以让软件更具有生命，维护拓展更方便？伸缩性更强?
对象和关系数据库的天然阻抗
软件是讲究方法的，要谈方法，这个世界只有两种：一是将复杂问题简单化的方法；另一是将简单问题复杂化的方法。对于软件这个领域，你只能选择前者。
面向对象与领域建模
据调查，目前有70%左右程序员是在使用OO语言编写传统过程化软件，缺乏完整的面向对象思维方法的教育和培训是基本根源，本文对软件开发中几个常见问题提出了独立的见解及尖锐的观点
Evans DDD 领域建模
如何提炼模型，而不是数据表，进而精化模型对象，使其能够反映领域概念基本本质是一个复杂过程，Evans DDD是2004年提出的具备革命性影响的软件思想。
实战DDD(Evans DDD:Domain-Driven Design领域驱动设计)
领域建模是一种艺术的技术，不是数学的技术，它是用来解决复杂软件快速应付变化的解决之道。
如何从职责和协作中发现丰富的充血对象？
失血模型贫血模型是DDD最大敌人，如何根据SOLID原则和GRASP原则设计业务行为？本文给出了DDD具体实践中一些具体细节，是和DDD配合一起进行面向对象分析设计的好方法。
业务模型统一描述
统一语言是DDD一个重要特征和重点。
Domain Events异步应用
领域驱动设计和异步架构完美实战解决之道。
DDD DCI和领域事件
将DDD DCI Event sourcing结合在一个案例中，展示OOA和OOD实现过程，直至可运行的源代码。
业务建模：CQRS应用场景
如何更好地在实践中实现DDD，又防止技术架构对业务领域的侵害，本文讨论引入CQRS使用场景。
不变性immutablity设计
不变性是统领业务分析和高性能架构重要法门，通过业务上不变性分析设计，可以实现代码运行的并发高性能和高扩展性
事件、契约设计与BDD
板桥banq提出中西结合的统一语言：场景 事件和状态，该文进行了论证。
DDD CQRS和Event Sourcing的案例：足球比赛
DDD + CQRS + Event Sourcing实现案例，结合代码与理论讲解。
集装箱车队系统的DDD案例
为上海某大型港口公司的运输系统实施的一个领域驱动设计DDD的实战咨询案例。
使用DDD聚合发现隐藏的业务规则的案例分析：数据库事务的业务实现
向领域驱动设计前进： 如何使用DDD实现从单体到微服务迁移打造业务平台或中台？