本次演讲是我创作GitChat课程「领域驱动战略设计实践」和「领域驱动战术设计实践」这两年来，随着对领域驱动设计的深度理解，结合自身项目经验总结的领域驱动设计知识体系。
领域驱动设计（Domain Driven Design，DDD）确实已不再青春，从 Eric Evans 出版了划时代的著作《领域驱动设计》至今，已有将近十五年的时间，在软件设计领域中，似乎可以称得上是步入老年时代了。
通过比较领域驱动设计和数据驱动设计，探讨为何基于数据库进行设计容易催生出贫血模型与事务脚本，指出领域驱动设计与数据驱动设计的不同之处在于限界上下文和聚合。
本文尝试指出领域驱动设计的四个不足。目前我们采用的领域驱动设计，其主线是Eric Evans提出的所谓领域驱动设计元模型。该元模型因其高度的概括性与松散性，故而能够随着时间推移历久不衰。但也正因为此，使得它在指导领域驱动设计落地时，缺乏规范性和实践意义，更多需要凭借经验才能成功实施领域驱动设计。
本文是我即将在GitChat发布的领域驱动设计第二篇「领域驱动战术设计实践」的开篇词。本课程预计会在5月初发布，内容承接「领域驱动战略设计实践」，敬请关注。
子领域、限界上下文、分层架构与聚合皆为领域驱动设计的核心元模型，分属战略设计和战术设计，贯穿了从问题空间到解空间的全过程。
领域驱动设计（Domain Driven Design，DDD）是由Eric Evans最早提出的综合软件系统分析和设计的面向对象建模方法，如今已经发展为一种针对大型复杂系统的领域建模与分析方法。它完全改变了传统软件开发工程师针对数据库进行的建模方法，从而将要解决的业务概念和业务规则转换为软件系统中的类型以及类型的属性与行为，通过合理运用面向对象的封装、继承、多态等设计要素，降低或隐藏整个系统的业务复杂性，并使得系统具有更好的扩展性，应对纷繁多变的现实业务问题。
述说撰写《解构领域驱动设计》一书的心路历程，三年磨一剑的认真态度与艰辛苦楚，如今写作完毕，也算是苦尽甘来。本书将由人民邮电出版社异步图书社区出版，敬请关注公众号的后续消息。
相信很多朋友对领域驱动设计会有这样或那样的困惑，比如领域驱动设计是什么？它在工作中有什么作用？为什么国内关于这方面的书籍少之又少？为了解决这些困惑，有幸邀请到专家张逸老师来聊聊领域驱动设计，下面是GitChat独家采访记录。
因为微服务，人们似乎才重新发现了领域驱动设计的价值，可惜的是，对于这样一个在国外 IT 圈享有盛誉并行之有效的设计方法学，国内大多数的技术人员却并不了解，也未曾运用到项目实践中。
领域驱动设计，方法论是为了解决软件核心复杂性的。也就是说软件业务越来越复杂了，领域驱动设计可以让事情变得简单。而实际情况是：领域驱动设计的门槛很高，没有很深厚的面向对象编码能力几乎不可能实践成功。
作者 | 张逸 最近重读Eric Evans的经典《领域驱动设计》，正如Eric提倡我们要去发现隐式概念一般，这次重读也让我发现了许多隐藏的DDD知识。恰好今日有朋友咨询我一些DDD问题，好似激活了触发器，随着问题的解答，我倒是在回答过程中又把这些知识梳理了一遍，才有了这篇杂记。 问题一：Repository的问题 怎么看待DDD中的Repository？我们必须把握一个根本的底线，就是采用DDD方式设计Repository时，一定要忘记所有与数据访问有关的技术实现细节。Repository接口属于领域层
在战略层次，需在领域驱动架构风格的约束和指导下考虑限界上下文之间的协作，思考并决策限界上下文的通信边界，思考从单体架构向微服务架构的演进，同时，因为进程间通信引起的诸多影响，需评估分布式通信、事务以及受技术因素驱动的命令查询职责分离模式是否对领域模型造成了影响。
领域驱动设计(Domain Driven Design,DDD)是Eric Evans提出的综合软件系统分析和设计的面向对象建模方法。它改变了传统软件开发工程师针对数据库进行的建模方法，从而将要解决的业务概念和业务规则转换为软件系统中的类型一级类型的属性与行为，通过合理运用面向对象的封装、继承和多态等设计要素。仔细想想，我们在开发项目时，是不是只是思考数据库的设计，围绕着数据库进行各种操作的呢！
架构是为了解决业务问题而产生的，没有了业务，架构就没有了存在的前提！在解决同一个业务问题的前提下，更高效更低成本的架构，会淘汰低效高成本的架构。DDD让架构更高效，打破了架构和业务之间的隔阂。其流行的意义就在此。
本文从需求分析到API设计，试图描述领域驱动设计的过程及思想。同时也能看的出领域驱动设计并不是孤立存在的，它为解决开发团队和业务人员之间沟通而生，进而驱动微服务的划分以及API的设计。
大约公元前800年至前200年间，中国、希腊、印度和以色列的文明几乎在同一时期兴起，这被称为人类文明的轴心时代。不同文明展现出了不同的风貌。中国古代文化强调辩证逻辑，重视变化、联系和综合的思维方式，同时又有“子不语怪力乱神，六合之外存而不论”的唯物主义倾向。古希腊则重视严格的推理和分析，孕育了形式逻辑和公理化的数学体系。印度在婆罗门和佛教哲学中，从另一个方向将辩证法、逻辑和语言学推向极致。以色列的先知则创立了一神论的犹太教和政教合一的社会体制。
最先介绍领域驱动设计（domain-driven design）的是在程序员 Eric Evans 2004年出版的《领域驱动设计:复杂软件核心复杂应对之道》书籍中，领域驱动设计是领域概念的扩展和应用，并且将它应用在软件开发中。它的目标是将软件相关部分连接到不断发展的模型中，以此更容易创建复杂的应用。
领域驱动设计，近年来受到技术圈的广泛追捧，主要得益于微服务技术的发展。一千个读者有一千个哈姆雷特，而不同的人往往对这种理论有不同的看法。如果问一个.net开发者领域驱动是什么，大概他会说是abp架构。ABP架构作为完全按照领域驱动设计思想构建的技术架构，目前得到了社区的广泛追捧。然而，领域驱动架构和领域驱动设计，依然是道和术的区别，开发者在学习领域驱动架构的同时，也应该了解领域驱动设计。那么领域驱动设计究竟是什么的东西？由于时间和篇幅有限，我无意通过代码介绍如何实现一个领域驱动的功能，而是希望把领域驱动设计的基本思路进行梳理，期待能通过我的梳理，抛砖引玉，给大家带来启迪。
如果有人不了解人体的内部结构，就自称医生，声称自己能给人开腹割掉发炎的阑尾，甚至还能开胸给冠心病人做心脏搭桥，你信吗？
这篇文章讨论领域驱动设计(DDD)，DDD是建立在面向对象分析设计上开发软件的一种方法。 通过这篇文章我们解释什么是领域驱动设计，在现代开发周期中如何实现，使用DDD的优点和缺点。
领域驱动设计（Domain-Driven Design，简称DDD）是软件开发领域的一种设计思想，由埃里克·埃文斯（Eric Evans）在他的著作《领域驱动设计：软件核心复杂性应对之策》（Domain-Driven Design: Tackling Complexity in the Heart of Software，2003）中首次提出。这种设计思想重视将实际业务问题映射到软件设计中，以解决复杂业务场景带来的软件开发问题。下面让我们来探索领域驱动设计的发展历史。
封面图：张子瞻的绘画，用丙烯颜料表达了蓝色的海、白色的波浪、棕黄色的沙滩以及墨绿色的树林。
应对复杂度的挑战，或许是构建软件的过程中唯一亘古不变的主题。为了更好地应对软件复杂度，许多顶尖的软件设计人员与开发人员纷纷结合实践提出自己的真知灼见，既包括编程思想、设计原则、模式语言、过程方法和管理理论，又包括对编程利器自身的打磨。毫无疑问，通过这些真知灼见，软件领域的先行者已经改变或正在改变我们构建软件的方法、过程和目标，我们欣喜地看到了软件的构建正在向着好的方向改变。然而，整个客观世界的所有现象都存在诸如黑与白、阴与阳、亮与暗的相对性，任何技术的发展都不是单向的。随着技术日新月异向前发展，软件系统的复杂度也日益增长。中国有一句古谚：“道高一尺，魔高一丈。”又有谚语：“魔高一尺，道高一丈。”究竟是道高还是魔高，就看你是站在“道”的一方，还是“魔”的一方。
正所谓有人的地方就有江湖，有设计的地方也一定会有架构。如果你是一位软件行业的老鸟，你一定会有这样的经历：一个业务的初期，普通的 CRUD 就能满足，业务线也很短，此时系统的一切都看起来很 nice，但随着迭代的不断演化，以及业务逻辑越来越复杂，我们的系统也越来越冗杂，模块彼此关联，甚至没有人能描述清楚每个细节。当新需求需要修改一个功能时，往往光回顾该功能涉及的流程就需要很长时间，更别提修改带来的不可预知的影响面。于是 RD 就加开关，小心翼翼地切流量上线，一有问题赶紧关闭开关。
目前我在看两本书《领域驱动设计精粹》和《实现领域驱动设计》，前一本比较薄，不到150页，后一本就非常厚实了，有500多页，那么读起来可能就会显得有点心理障碍，但如果要想更多了解DDD，还是要以第二本为主，第一本可以作为概要性阅读。
断断续续的也有在闲余时间接触领域驱动设计的相关知识，因为目前在工作中更多的还只是一名 crud boy，因此目前也只是对其中的某些知识点有知晓，实际使用的比较少，仅此而已。因此，趁着这个春节假期，整理了一下自己的 github 帐号，同时结合自己定的学习计划以及自己的期望发展方向，决定从一个真实的案例来梳理领域驱动的相关知识。
冯友兰治哲学，提出“照着讲”和“接着讲”的方法论。近两年，我断断续续梳理出关于领域驱动设计的两个 PPT：《领域驱动设计》和《领域驱动设计四论》。前者的内容主要是关于 DDD 经典著作的读书笔记，可视为照着讲，以证明自己学有所本，讲的不是野狐禅；后者则是在继承的基础上所做的创新阐释，可视为接着讲，发前人之未发。本文重点围绕《四论》展开，从四个方面梳理出 DDD 的整个逻辑脉络。
我在GitChat上最新开通了一个Chat，主题为：限界上下文的菱形对称架构。为有利于搜索，更名为：领域驱动设计的菱形对称架构，但主要针对的是领域驱动设计的核心模式：限界上下文（Bounded Context）。
由于本次研究需要采集大量工程实践的调查样本，故而钟博士与其他研究者共同拟定了附于文末的调查问卷。为了更好地获得来自领域驱动设计推进一线的真实反馈，我诚挚希望各位读者能够踊跃参与本次调查，发表您的真实意见。参与者并有机会获得由人民邮电出版社异步社区赠送的《解构领域驱动设计》实体书，后期还可以收到我们整理后的调研报告内容！多谢捧场！
领域场景驱动设计实战工作坊将以事件风暴为纵贯线，以领域场景为横切面，引入场景驱动设计与测试驱动开发完成从领域建模到编码实现的全过程实战。内容涵盖事件风暴、场景驱动设计和测试驱动开发。整个工作坊围绕为学在线课堂的案例全程演练具有实操价值的领域驱动设计方法。
作者：larkliu，腾讯 PCG 后开开发工程师 经过多年的研究与思考，实践与总结，本人逐渐对 DDD 有所领悟，本文以一个较短的篇幅，提纲挈领地梳理出 DDD 的核心脉络，希望与各位做一探讨。 1776 年亚当斯密发表《国富论》，标志着经济学的诞生。2004 年，一本名为《领域驱动设计·软件核心复杂性应对之道》的书问世，开辟了软件开发的一个新流派：领域驱动设计。看完这本书，十个人有九个人的感觉都是：似懂非懂，若有所得，掩卷长思，一无所得，我个人的感觉同样如此。出于兴趣，多年来仔细研读了几十本相关书籍，融
潘老师：我正在看*老师的“**领域驱动设计”，有个问题请教一下，这副图上的不变量觉得很别扭，是不是多余了？您有没有进一步学习不变量的资料推荐呢，我也在追更您的下册，里面似乎没有说到。
简单来说，动用大量的资源只为了一套优质的三高架构并不正确，而是该在了解当前业务现状的情况下，创造出灵活、可维护、健硕能成长的。
时间是人类最宝贵的资源。时间是有限的、不可再生的，你可以用钱买任何东西，却买不了时间。技术，就像时尚，在以光速在变化着。为了赶上它，我们需要跑的非常快。但是这个跑道上没有终点，所以没有赢家。
把时间拨回到 90年代，关系型数据库系统如Oracle、IBM DB2和Microsoft SQL Server等逐渐成为企业和互联网应用的主流选择；在软件架构设计上，随着关系数据库的迅速发展，以数据层作为基座的三层模型（数据访问层、业务逻辑层、表现层）逐渐兴起成为了主流架构设计。回想当时的三层模型架构，颇有一番类似如今到处都在谈论微服务架构、领域驱动架构的味道。
领域驱动设计就是我们俗称的DDD，英文全拼是Domain-Driven Design。
在我写《解构领域驱动设计》一书时，真正确定“业务服务”名称，是在完成初次审稿的时候了。最初的名称叫“业务活动”，它是问题空间进行需求分析的基本业务单元。到了解空间，在进行领域设计建模时，我将其“改头换面”，称其为“服务场景”，由此有了“场景驱动设计”。
我们都清楚领域驱动设计，作为应对复杂情形下的软件工程思路，实际上受到了传统软件思维的广泛影响，例如之前提到的实体和值对象、以及服务和包（模块）实际上在非领域驱动设计中同样普遍存在。但是聚合和聚合根的思想，应该属于领域驱动设计中独特的知识点，进一步加强这个知识点的认识，将有助于我们更好的进行聚合设计，从而更好的设计一个符合实际应用场景的应用系统。
随着互联网服务及FinTech创新的发酵，中国金融市场正在经历着一波变革。这场变革的核动力毫无疑问来自于科技的发展和引领，而软件构建的生态是现代科技能够为我们所用的基石。如何构建高效响应市场变化的软件生态成为了每一家金融机构必须完成的优先级任务。金融IT从过去的成本中心必然需要转型成为发展引擎，而这样的转型需要我们的软件设计者们重新思考软件架构。
关于UML、《软件方法》各种评论很多，评论、疑问或质疑的内容没有到一定水平或者造成巨大影响，我基本上是不回应的。我回应的问题是怎样的，可以看《UMLChina公众号文章精选》的“精品文章”和“答疑”部分。
微服务构建本质上是软件构建过程中长期演进积累的一系列理念、架构原则、工具和最佳实践。
在整个过程中，与团队成员和相关利益相关者进行有效的沟通和协作非常重要。确保你理解需求，并根据实际情况进行适当的调整和改进。此外，遵循良好的分布式系统设计原则和最佳实践，可以提高应用的性能、可靠性和可扩展性。
领域驱动设计（Domain-Driven Design，DDD）是一种软件开发方法论，旨在将软件系统的设计与业务领域的实际需求相结合。在DDD中，设计和开发围绕着领域模型展开，以解决复杂业务问题和满足业务需求。本文将介绍DDD实践原则规范，包括聚合根、实体与值对象、资源库、工厂、领域服务、命令对象、业务中读写操作以及与工具技术结合使用原则。
有一个古老的故事，大概是这样的。作者问三个建筑工地上的工人他们在干什么？有一个没精打采的说，我在挖洞！而另一一个人却说，我在盖一座房子。还有一个人说，我在建立一座巨大的城市。不同的思维模式决定了不同的发展，十年过后，第一个工人，还是在挖洞，而第二个则成为了工头。第三个最终却成为了大设计师。
硬核分享简介 10.29丨《用领域驱动设计驱动系统重构》 硬核大咖：李智慧 同程艺龙 交通首席架构师 硬核简介：为什么互联网应用越是发展到成熟阶段，需求变更越是困难，开发周期越是变长？为什么系统功能似乎没有增加多少，但是代码却变得越来越庞大？如果系统重构是不可避免的，应该用什么样的设计思想和方法来引导我们进行系统重构。《用领域驱动设计驱动系统重构》通过一个交通出行互联网应用的重构案例，展示随着功能不断迭代开发，系统开始腐坏变味的时候，如何利用领域驱动设计的方法驱动系统进行重构。 硬核大纲： 1.为什么用
6年前同事问，如何学架构，给同事的答案是学习《领域驱动设计》，几年过去了，领域驱动设计开始开花结果。这个PPT是学习DDD设计的很好资料。
在上一篇文章，我通过12306购买车票的例子详细阐述了业务服务的定义，以及该如何识别业务服务。有好几位读者热情参与了这一练习，完成的质量也都不错。有一位读者哀嚎说被我“批判”了，但随即也表示：通过对练习答案的点评，更有收获。
随着业务的变化、系统设计也要演进升级。好的架构设计一定演化来的，不是一开始就设计出来的，但系统演进过程中的成本，一定是最开始的设计决定的。一个健康公司的成长，业务横向、纵向会发展的会越来越复杂，支持业务的系统也一定会越来越复杂。在领域驱动设计中，域模型对应的是业务模型，是系统架构的内核，通过域模型来驱动与外界的交互。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
