1-1 DDD课程导学

所以大家好，我是尤达，欢迎来到我们深入领域驱动设计。
这门课程。
从我们的副标题结合智慧零售项目实践，深度解剖滴滴滴思想与应用方法。
我们可以看到这是一门理论结合实际的课程。
首先呢让我们来了解一下我们为什么要学以及如何学习滴滴滴。
我们先来看一个图，大家知道软件开发工程师相对来说是一门高薪的职业。
那这种高薪呢可能还会持续相当长一段时间。
但是呢我们也必须要认识到一点，那就是软件开发人员的数量是在不断增加的。
第二个图呢是我们国家GDP增长速度的一个趋势图。
我们可以看到，我们的经济增速目前是在不断降低的，我们会从追求数量转变到追求质量。
这一点呢，政府的经济部门也在不断的强调发生这种转变的一个主要的原因是因为我们经济发展的早期红利已经逐渐消失了。
那么也就意味着空白领域在不断减少。
此外呢我们的实体经济和tob的业务会逐渐成为发展的主战场。
这就是为什么最近有一句话会不断的被提到，那就是深化数字化转型。
这句话是什么意思呢？
所谓的数字化，我们可以说直白一点，就是指以前需要人工去完成的工作。
我们现在要通过软硬件系统去完成。
那以前线下的数据呢，我们都要把它转到线上来。
而所谓深化呢，顾名思义就是说我们以前简简单单能做到的事情现在都已经做完了。
那么接下来要做的呢，就是以前做不到的事情。
现在我们一些热点的方向，包括智慧城市啊智慧物流啊智慧零售啊等等等等。
其实都是这句话的体现。
那么这种深化呢就会意味着我们的软件的业务复杂性会不断的提高。
这一点不难理解啊，因为简单的事情做完了嘛，那接下来你就只能做复杂的事情了，所以这是我们软件系统发展的不可避免的趋势。
那么面对复杂系统呢，我们原有的一些架构模式和设计方法呢，就会显得捉襟见肘了，不够用了。
面对复杂系统，如果我们还是只会CRUD的话，那是一件很危险的事情。
不仅如此，我们传统的面向对象的分析建模和设计方法在面向复杂，系统的时候也会显得力不从心。
而d滴滴呢正是用于应对软件系统的业务复杂性的。
而且呢它也能够做到，正是因为这一点呢在近几年来领域驱动设计，它的热度在不断的提升，并且呢在面试和应用中也越来越多的被涉及到国内的一些主流的互联网公司和软件公司都开始越来越多的用到DDD对相关的人才需求呢也越来越大。
在面试过程中也越来越多的会提到滴滴滴。
所以我们学习滴滴滴一方面是要适应市场的需求。
此外呢我们来看一下滴滴滴在我们的职业发展过程中能够起到什么样的一个作用。
我们技术人员的职业生涯整体上可以划分为四个阶段。
第一个阶段叫做学徒工阶段。
在这个阶段呢，我们只能根据领导的安排，完成一些简单的工作，主要就是CRUD这种。
第二个阶段呢就是我们经过了两到三年的工作和学习，在技术方面不断精进，开始能够完成一些有难度的重要的工作了，会负责一些难点重点模块的开发。
那这个时候呢叫做骨干阶段。
第三个阶段呢，叫做架构师和骨干相比，架构师除了技术深度以外，更重要的他还需具备备系统架构设计的能力。
从骨干架构构师是一个巨大的跃迁，只有成为了架构师，你才能够对业务产生直接的影响，从而呢也能够得到更多的个人发展机会。
最后一个阶段呢是行业专家在架构师之后呢，借助一些机遇以及自己不断的精进假，以时日呢就有可能成为行业专家。
那行业专家呢就代表了一个行业方向的最高水准，也有能力引领一个行业的发展成为行业专家呢当然是可遇不可求的。
那么学习滴滴滴呢，可以在我们从骨干向架构师跃迁的这个过程中发挥重要作用。
因为如果我们真正学懂，学会了领域驱动设计，那么其实我们就已经具备了业务架构设计的能力，也就是一个架构师应有的能力，不排除有的同学可能会说，架构师好像离我有点远呀，我还想在骨干这个阶段再多待几年，那么学习DDD对我还有用吗？
当然也是有用的CCDDD可以让你更能理解你领导的意图和思路，从而对工作呢也能形成实际上的帮助。
那么也就让你在团队中更容易受到重视。
但是呢长久以来我们学习d滴滴都一直存在着一些困难。
比如说DVD的概念太过抽象。
虽然每个字我们都认识，但是连在一起呢，可能就不太那么好理解了。
第二呢就是只闻其声不见，其用什么意思呢？
就是我们经常能听到大家谈论滴滴滴。
但是在实际应用中呢就见得比较少了。
所以往往我们也没有太多机会去学习滴滴滴的应用。
第三点呢就是知其然不知其所以然。
可能我们知道根据滴滴滴的思想应该这样或者那样。
但是呢在没有真正理解滴滴滴思想的情况下，我们不知道他为什么要这样做，也就没有办法在面试或者应用中灵活的运用滴滴滴。
那么针对这些困难呢，我梳理出来了一个学习滴滴滴的有效思路。
我们知道任何概念和理论的提出呢，他都是为了解决实际问题的。
我们在学习他们的时候，一定要从他针对的问题出发。
在学习滴滴滴相关的概念和方法的时候呢，我们需要从问题出发，对他进行分析，以求能够真正的理解这些概念和方法。
当然这还不够，我们还要把它应用到我们的案例实践中去。
通过案例呢来学习这些方法的应用，并且通过案例，我们也能够更好的理解这些问题，甚至发掘出来更多的问题，以及看看滴滴滴是怎么去解决这些问题的。
这个铁三角呢就是我们学习滴滴滴的一个有效的方法，也是贯穿于我们整个课程的一个思路。
那么在我们学习过程中呢，我们不仅会去学习滴滴滴的概念和理论，也会去学习具体的建模分析方法。
比如说领域故事陈述法事件风暴剑魔法，并且呢我们还会深入到代码层面，我们会学习怎么样？
基于滴滴滴的思想来进行代码的编写。
那么这么看呢，案例在我们的课程中会起到一个比较重要的作用。
我们会用一个智慧零售领域的案例项目，来贯穿我们整个课程的学习。
这个案例项目呢跟我们日常经常会用到的自动售卖机有关。
它是一个sars系统，它会为我们的用户在售卖机上购买商品提供交易系统，也会为我们的业务运营人员对售卖机业务进行运营，提供相关的运营系统。
它还会跟我们的客户的内部系统，包括erp商品中台配送中台这些进行对接，客户自己呢会为售卖机提供商品和配送服务。
我们的saars软件呢就是卖给零售行业的这些客户的，我们管它叫smartRM系统。
那么接下来呢让我们来看一下我们的课程的安排。
首先我们会学习滴滴滴的背景和来源。
这一章呢包括DDD的核心思想与解决的痛点问题DDD发展的过去现在与未来以及面向对象和敏捷与DDD的区别和联系。
接下来呢我们会学习DDD的战略设计。
首先呢我们会对我们的案例背景进行介绍。
然后呢，我们会学习建模和设计的整体流程。
怎么样建立通用语言子域和领域划分核心域与精炼上下文映射和分层架构。
接下来呢我们会对战术设计进行一个初步的学习。
首先我们会对开发环境进行一个准备，并且呢对我们的基本约定和架构进行一个说明。
接下来我们会学习战术设计的分析方法，并且为我们的核心域之一交易域做好依赖准备方面的工作。
我们会学习实体和值对象的概念和应用领域对象的构造方法资源库与持久化，聚合礼域服务应用层的实现。
接下来我们会对战术设计进行更深入的学习。
我们会学习领域事件和事件风暴建模法。
我们会基于世界风暴建模法，对我们的核心域之一运营域进行建模，你会学习怎么样去构建防腐层。
最后我们也会学习滴滴滴在大数据ETL和分析场景中的应用。
然后呢，我们会对我们的案例项目进行从单体到微服务架构的升级，从而学习d滴滴和微服务的关系，以及DDD在微服务架构中的应用，我们会学习为什么要微服务实施微服务架构的前提和基础微服务的问题和DDD提供的答案。
微服务主流框架的简介，我们会基于DDD的思想进行服务拆分，并且基于服务网格技术对我们的案例系统进行微服务的改造。
最后呢我们会使用k八s进行服务编排，把我们的服务部署上云。
接下来我们会对滴滴滴实践中的一些问题和关键点进行一些补充学习，包括持续集成的重要性以及如何搭建持续集成系统在滴滴滴的沟通和分析过程中，如何避免漏掉重要细节？
滴滴滴的局限性，它不能解决什么问题，我们不能拿着榔头，就看什么都像钉子。
滴滴滴也有它的边界。
最后呢我们会进行总结与展望，我们会对滴滴滴的核心思想与方法进行回顾。
然后我们会聊一下程序员的技术生涯学习。
这门课程呢需要大家有一些基础的技术储备，主要包括我们需要对java语言有一个基础的掌握。
然后呢了解springboot的基本应用，至少要能看懂基于springboot的代码。
最后，祝大家能够真正学会学懂滴滴滴为今后找到更好的工作升职加薪，成为一个优秀的架构师打好基础。
那么还犹豫什么呢？
接下来就让我们一起开启领域驱动设计的探险吧。

1-2 DDD的核心思想和解决的痛点问题

大家好，这节课我们先来了解一下DDD的核心思想和它要解决的痛点问题是什么？
这节课我们会按照这个脉络来学习。
首先我们探究一下什么是模型，以及什么是建模？
接下来我们需要理解软件的复杂性是来自哪里？
在此基础上，我们才能知道DDD它是如何控制软件系统的复杂性呢？
它解决的是什么痛点问题。
首先让我们来看一下什么是模型。
那我们提到模型的时候呢，大家首先会想到的，它可能不是一个真实的东西，它是对现实事物的一个模拟，小到汽车大到航空母舰都可以有自己的模型。
的确是这样。
所谓模型呢，它就是对现实事物的模拟，就像这张图上，我们画了几个框框在里面填了一些属性。
通过这种方式呢，我们试图去描述零售领域里面几个关键的概念，包括商品啊库存啊门店呀订单呀这些。
此外呢我们通过这些框框之间的线条和箭头尝试，描述他们之间的关系。
这个图呢其实就构成了这种领域里面一个比较简单的模型。
那么我们为什么要去建立这样一个模型呢？
此因为我们要开发一个软件系统，通决相关领领域里面的问题。
比如这个模型就是为了解决门店里面对商品的管理和销售问题。
所以什么是模型呢？
所谓的模型其实就是对门域的抽象和问拟。
而所谓的建模呢就是针对特定的问题，建立领域的合理模型。
那这里其实就隐含了一个信息，说同样的事物在面对不同的领域不同问题的时候呢，它可能模型是完全不一样的。
也就是说模型它一定是针对特定的问题，特定领域的模型订单库存这几个概念在电商平台系统里面和在超市的进销存系统里面，他们的模型是完全不一样的。
比如说商品这个概念在电商平台里面，商品的属性，商品的标签，商品的图片，它可能都是商品非常重要的组成部分，因为客户需要对商品进行挑选。
但是在超市的进销存系统里面呢，就完全不一样了。
因为我们进超市买东西都是现场挑选，即拿即走的。
那么商品的属性图片和标签这个概念呢可能就相对没有那么重要了。
但是我们拿到商品之后呢，交给店员进行扫码，然后生成订单。
我们要对订单进行支付，扫码确认之后呢，超市还可以对商品的库存进行实时的修改。
也就是说商品条码这个概念对超市的进销存系统来说是比较重要的。
同样的订单这个概念在两个系统里面也完全是不一样的。
在电商系统里面的订单就是类似一种合约订单，经过了复杂的生产配送环节之后，商品才能最终到达用户的手上。
但是在超市的进销存系统里面呢，订单只是支付购买的凭据和商品销售事件的记录而已，订单的处理也相对比较简单。
所以通过这个例子呢，我们可以看到确实同样的事物在面对不同领域不同问题的时候，它的模型是不一样的。
也就是说建模它一定是针对领域问题的建模。
对于软件系统的开发来说呢，我们首先要建立它的模型，然后才是把模型转换成代码。
也就是说，软件系统的开发是要经历两个阶段的。
第一个阶段，就是我们的建模阶段。
也就是把领域知识和业务需求转换成领域模型。
第二个阶段才是我们的设计阶段，也就是把模型转换成代码。
这个阶段需要考虑的是技术实现。
也就是说，采用什么样的技术方案，才能让这个系统的性能啊可靠性达到最高软件系统，最终复杂性的来源。
也就是这两个阶段。
首先，业务本身的复杂性和领域知识的复杂性。
在建模阶段会导致你的模型复杂性的增加。
也就是说第一层的复杂性是隐含。
在建模这个过程的其次呢也就是设计过程中，技术实现也可能会引入额外的复杂性。
打个比方说可能有一些技术人员，他喜欢新兴的复杂的技术。
因此，他设计的技术方案会挑选那种比较性感比较复杂的技术。
此外，他可能还会在设计里面引入一些本来可以不用的设计模式，这也也有可能会导致系统在实现的过程中引入不必要的额外的复技术复杂性。
我们要控制系统的复杂性，也就是要从这两个阶段去入手。
我们先来看一下例子，百元大钞。
这个对象对于我们普通人来说呢，这可能是一个再简单不过的对象了。
可能我们用一个数字就可以描述它的确对于财务领域来说，可能我们只需要币种和数量是两个属性，就可以描述这么一张钞票。
但是如果把这张百元大钞放到印钞厂里面呢，它就完全是不一样的概念了。
大家知道印钞厂里采用的技术都是非常复杂的。
那么这样一张钞票，它作为一个印钞印刷厂的产品来说，它要考虑的属性就非常多了，包括它的编号，它的面额，它的日期版本等等，再更进一步。
如果我们要考虑的是防伪问题呢，它的复杂性就更高了。
可能我们要考虑它的形状颜色，它的图案，它的重量它的防伪标签等等。
通过这个例子，我们可以清晰的看到同样一个事物在面向不同的领域财务印钞和防伪。
这三个不同领域的时候，他们的复杂性是怎么样逐步提升的。
也就是说业务的复杂性它是怎么样导致模型变复杂的，那么让我们更进一步。
假设我们要开发一个这样的系统，假要同时考虑这三个领域，同时要解决财务方面的问题，印钞的问题和防伪的问题。
就比方说我们就是要开发一个非常现代化的印钞厂的内部系统，包括它的生产系统和ERP系统。
假设我们要用一个模型解决这三个领域的问题会怎么样呢？
很可能我们会得到一个非常复杂的模型。
首先，前这个对象的模型就会变得非常复杂，因为他要融合三个领域里面要考虑的因素。
其次呢对象和对象之间的关系也会融合起来，变得异常复杂，也就是形成右边的这个大泥球。
当我们要同时考虑这三个领域的问题的时候呢，假设我们要用一个模型去面对。
那么这个模型就会变得错综复杂，这个其实就是在传统的面向对象思想它存在的问题。
在d滴滴市场出现之前呢，他也一直是一个痛点问题。
当我们的业务变得非常复杂的时候，如果我们还是用面向对象的思想去对它进行建模，最后用同一个单一的模型来描述这个系统，那么它的复杂性就会变得不可控。
所以呢我们要介绍一下滴滴滴核心思想的第一个思想，也就是如何通过模型分解用不同的模型去面对这个系统里面不同的问题PDD里面提供了两个工具来做这个事情。
第一个是领域划分，第二个是限界上下文。
首先通过领域划分，我们可以把这个系统划分成不同的子领域，然后对不同的子领域分别进行建模。
那么对人民币这个例子来说，在不同的子领域的模型里面，它其实就是不同的概念。
也就是说它是属于不同的限界上下文这些知识点，我后面我们在课程里面还会详细的进行分析和学习。
这里大家只要对这些概念有一个基本的了解和印象领域划分呢，它是面向问题空间的先接上下文呢，它是面向解决方案空间的。
通过这两个工具，我们就可以把本来一个复杂的系统划分成不同的模型，他们面向不同的子领域解决不同的问题。
这样它的复杂性相当于就得到了管理。
那么我们再来通过另外一个例子看一下第二层的复杂性。
也就是说技术实现是怎么样引入复杂性的。
假设我们要开发一个电商平台系统。
在这个系统里面呢，商家要负责传入商品数据和门店数据。
而我们要构建商品对应的服务，包括商品交易啊商品搜索等等。
假设我们有两个团队，负责整个系统的开发工作。
第一个团队呢专门负责数据接入服务的开发。
第二个团队呢专门负责商品服务，包括商品交易啊，商品搜索服务的开发。
对于负责数据接入服务开发的同学来说呢，它原本它的业务逻辑非常简单。
当商家传入商品数据的时候，他只要建立商品的实体，然后把这个实体写入到商品表里面。
然后当商家传入门店数据的时候呢，他只要建立对应的门店实体，然后写入门店表就行了，概念和操作都非常呃简单和清晰。
但是呢假设进行商品服务开发的同学在开发商品搜索服务的时候，他需要提供对门店或者是针对地理位置信息这种信息的搜索。
比如说他可能需要提供这么一个功能，让用户可以优先搜索到附近的商品，那么他可能就需要把商品数据和门店数据进行一个结合，然后通过这个数据来进行处合。
那为了提高搜索的实质性呢，商品服务的同学，他可能会和负责商品接入的同学进行商量，最终他们决定让数据接入服务的同学在写入商品数据和门店数据的时候呢，同时构建搜索服务，他们所需要的数据。
也就是说，负责商品接入的同学才写入商品数据和门店数据的时候，还需要生成一个所谓的门店商品这样一个数据融合了商品数据和门店数据，其实就是为了让商品数据带上门店的地址坐标名称等等这些信息，以便他们在构建商品搜索服务的时候呢，可以更方便实续性。
可以更高。
但是呢这样一个设计会导致除了商品接入服务会引入额外的复杂性之外呢，整个系统它其实也会相对变复杂，因为它会引入额外的一个概念，叫做所谓的门店商品。
这个概念会在这整个系统中流转，负责数据接入服务的同学，在接入商品和门店数据的时候呢，他同时还要构建额外的实体，也就是所谓的门店商品实体。
那在构建和写入这个实体的时候，他有可能会涉及到各种各样的逻辑，这个逻辑可能会相对比较复杂。
比如说他可能会考虑到当门店数据在商品数据之后到来的时候，那这个门店商品的数据怎么去构建呢？
也就是说，他可能会有业务概念和业务逻辑之外的概念和逻辑，这就会导致他的技术实现偏离了模型，原本应该有的样子。
也就是说引入了额外的复杂性。
在d滴滴之前的年代，分析建模和设计两个阶段的工作可以完全脱离关系不行，驱动设计其实是一种理念，也就是通过仔细的选择模型和设计方案来保证实现和模型的一致。
也就是说，在设计过程中，不要引入太多额外的复杂性。
d滴d里面的确提供了一些理论工具，并能够帮助达到这种一致。
比如说它会有架构分层的设计，包括构建防腐层等等。
这些方法它都可以帮助我们达到模型和设计的一致性。
但是其实本质上模型驱动设计还是一种理念。
因为他认为解决同一问题，除了技术方案可以不一样之外，它的模型其实也可以不一样。
在众多模型中，你应该选择一个最合适的模型。
而这个模型呢它可以帮助你达到模型驱动设计这个目标。
我们拿刚才这个例子来说，它更合理的方式是怎么样的呢？
那么我们可以把搜索这个子领域单独拉出来，然后搜索这个领域会从商品业务领域获取相关的数据，那需要做一个转换成把它转换成自己需要的模型。
这个转换成后面。
我们会知道我们一般称它为防腐层通过类似的建模层面和设计层面的一些处理，我们可以最终达到模型驱动设计这个目标OK让我们来回顾一下今天的一个核心逻辑。
首先我们了解到了什么是模型，以及什么是建模模型，是对领域的抽象模拟，而建模是对特定问题建立领域的合理模型系统的复杂性，主要是来自于两点，第一是建模。
第二是设计，也就是说系统的复杂性，第一是来自于业务本身的复杂性。
而第二是来自于设计引入的，由于技术实现带来的额外的复杂性，传统建模和设计方法。
面对这两种复杂性是无能为力的。
这也是开发人员一直以来面临的痛点问题。
那领域驱动设计是怎样去控制这些复杂性的呢？
首先它通过模型分解用不同的模型来应对不同的领域问题，把一个复杂的系统划分成几个相对简单的模型进行描述。
其次呢他通过模型驱动设计这样一个理念来控制设计引入的额外的复杂性。
这就是我们今天的内容，谢谢大家，我们下节课再见。

1-3 面向对象和敏捷与DDD的区别与联系

hello，大家好，这节课呢我们要聊的是面向对象和敏捷与d滴滴的区别与联系。
大家知道在d滴滴之前呢，其实软件开发领域已经有一些思想和理论，其中最主要的就包括面向对象和敏捷。
那么我们了解面向对象和敏捷与DDD的区别与联系呢？
也会有助于我们对DDD的学习以及把它应用到现实工作中。
什么是面向对象呢？
当我们提到面向对象的时候，其实是有歧义的。
因为面向对象它本质上包含两个层面的意思。
第一个层面就是我们的OAD也就是面向对象分析和设计。
那在这个层面呢，他做的事情和DDD其实是同一件事情，也就是怎么样把领域知识和需求转换成模型，然后再把模型转换成技术方案和代码设计。
那这个和DDD是在同一个层面上的。
那么另外一个层面呢，就是更底层的面向对象编程技术，像python啊c加加呀java呀，他们其实都是面向对象变成语言。
不管是OAD还是DDD呢，或者是其他的建模和设计方法，最终在软件落地实现的时候，都会依赖面向对象编程技术和各种面向对象变成语言。
那么我们今天要讨论的呢，就是OOAD和DDD也就是第一个层面，它们之间的区别和联系。
其实在上一节课，我们大概已经提到了一点。
我们以人民币这个案例为例子了解到OAD它在面对大规模的复杂的软件系统分析和设计的时候呢，它其实是有些局限性的原因是OAD它其实没有一个合适的对系统进行划分的方法。
所以在面对大规模的复杂的软件系统的时候呢，它会把多个问题多个子领域揉到一起去考虑。
所以得到的模型呢它其实是融合了多个问题，多个子领域的模型。
那这个模型呢不管是对象本身的复杂性，还是对象和对象之间的关系都会变得异常复杂。
它的复杂性很难得到控制。
而这一点，在滴滴滴思想出来之后呢，就得到了本质上的改变。
因为d滴滴专门有一个战略设计的部分，它会对软件系统面向的问题，面向的领域进行一个拆分。
最后得到的模型呢也是一个拆分之后的模型。
所以最后整个系统得到了分，而自之复杂性也就得到了控制。
这个也是d滴滴的一个最大的优势，这是他们之间第一个区别。
除此之外呢，在对具体的现实事物进行描述的过程中，OAD和DDD也是有区别的。
在OAD的世界里面，所有的东西都是对象，他仅仅用对象和对象之间的联系来描述这个世界。
而对滴滴机来说呢，它的描述会更加细致一点，对象可以进一步的区分成实体和值对象。
除此之外呢，它还有聚合呀聚合根等等的概念。
所以它对于模型的描述其实是更细致的这一点，让我们在进行设计的过程中呢，也就是把模型转换成代码，这个过程中呢就会更清晰更简单，也会更容易接近我们上一节提到的模型驱动设计这个概念。
那从这个层面上来说呢，系统的复杂性又得到了进一步的控制。
这个就是DDD与OAD它的核心的区别。
但是同时呢他们其实也是有联系的。
首先，不管是OAD还是DDD它解决的都是建模和设计的问题，他们都是现模合设计的思想。
此外，在面向对象时代曾经出现的一些建模方法和工具。
其实在某种程度上，在DDD里面也可以进行复用。
比如说像用力分析啊类图啊序列图啊等等。
其实在一定程度上是可以进行复用的那这个就是OAD和DDD的联系和区别。
我们来看一下敏捷，什么是敏捷呢？
其实敏捷是针对软件工程初期的一种瀑布流式的开发模式来进。
我们知道在上个时代，每个软件它的主体都是放在一个版本去开发的软件工程，会把这个版本划分成几个大的阶段，包括计划阶段呀需求分析阶段呀设计阶段呀实现阶段测试阶段，最后是部署和运维按顺序走下来。
每个阶段的输出是下一个阶段的输入信息不会逆向流回来，也就是不会有反馈机制。
那不管是多大的软件系统，在这个开发模式下面呢经过这几个阶段的生产，那最后就尘埃落定，形成它的一个稳定的版本。
后续的版本呢，只是对这个版本的小规模的修改。
但是这样一个阵地战式的开发模式呢，在后面大家发现存在一些比较严重的问题，存在一些风险。
什么风险呢？
就是他们发现在这样一个瀑布流失的开发模式里面，前期的一些错误，包括需求分析阶段的一些错误，设计阶段的一些错误，可能到了很后面才会被发现。
也就是到了测试啊，甚至到了投入应用之后，才会发现有问题。
那到了这个阶段，我们要纠正前面的一些阶段的错误成本就会变得异常的高软件失败的风险呢也就急剧提高。
大家发现这个问题之后呢，就提出来一个敏捷的错误，也就是从流程从开发文化方面对瀑布流的思想，以及对软件工程早期的一些思想进行了一些颠覆性的修正。
所以敏捷它其实主要包含两个方面的内容，一个是开发流程方面，一个是开发文化方面，从开发流程上的敏捷开发流程，把之前一个大的目标分解成了多个小的目标。
也就是说，把软件开发过程分解成了多个比较小的迭代。
每个迭代敏捷称它为一个冲刺。
所谓冲刺，顾名思义呢肯定是只能对短距离才能冲刺。
如果是跑马拉松，谁能去冲刺呢？
对吧？
那在这里瀑布流失的开发模式就可以认为是马拉松。
而敏捷呢就是把这个马拉松分解成了一百个百米冲刺。
可以这么理解。
但是在每个冲刺里面呢，它依然有分析和设计的过程，依然有开发测试部署运维这些过程。
那滴滴滴呢，这是对每个冲刺里面可以用来解决系统的建模和设计问题。
所以滴滴滴和敏捷它其实是一个互补的配合的关系。
因为他们解决了软件工程里面不同的问题，刚才提到了敏捷的一个开发流程上的改进。
那除此之外呢，敏捷还有他开发文化上的一些看法。
但我们在谈论文化的时候呢，我们主要是在谈论价值观和原则。
那么敏捷的价值观是什么呢？
让我们来看一下著名的敏捷宣言。
其实，核心就这四句话，个体和互动高于流程和工具工作的软件高于详尽的文档客户合作高于合同，谈判响应变化高于遵循计划。
另外它还有它的首要原则，具体我们就不念了。
这里我们主要想说的是什么呢？
我们想说的是敏捷，它的主体内容其实主要是包含了研研发流程和开发文们化方面的内容。
所以呢滴滴滴与敏捷的关系是什么？
首先他们都是软件工程里的思想，他们解决的是软件工程中不同的问题。
一般在现实生活中呢，我们也会把它结合应用这一点和OAD是有一些区别的。
具体而言呢，敏捷只关注流程和文化。
而d滴滴关注的是建模设计和方法，因此呢他们是互补的关系。
此外刚才我们看到了敏捷的开发文化里面，它其实有一点它是重人员轻文档的。
但是呢滴滴滴在这一点则稍有不同，它重视统一语言的建立。
而文档对于统一语言的建立，它是必不可少的。
这个就是滴滴滴和敏捷的一个关系和区别。
明白了d滴滴和面向对象和敏捷的区别与联系。
我们就知道在后面对d滴d的学习和应用过程中，它的关键点是什么？
我们要怎么样去处理他们之间的关系。
最后我们来总结梳理一下，在DDD之前，软件开发主要应用的分析建模和设计方法是面向对象OAD他和d滴滴做的是同一件事情。
而且OVD时代部分的建模方法和工具某种程度上，在DDD里面可以复用，这是他们的联系。
但是呢面向复杂系统OAD做的不够好。
相比之下，滴滴滴的战略设计和更细致的模型描述方式可以使得复杂系统能够被分而制之，并且代码和模型更容易趋向一致，这是他们的区别，或者说DDD的优势而敏捷开发模式和DDD的联系是他们之间是互补和配合的关系。
在现实中往往结合使用敏捷负责开发文化和开发流程DDD呢则负责建模和设计方法。
因此区别就是他们解决软件工程中不同的问题。
此外呢敏捷重人员轻文档这种价值观在DDD中会有所纠偏。
滴。
滴滴在建立统一语言的时候，需要依赖文档，这可以认为是另外一个区别OK这就是这节课的内容。
我们下节课再见。

1-4 DDD的过去、现在与未来

hello，大家好，这节课我们来聊一下DDD的过去。
现在与未来我们会从DDD的诞生聊到发展历史。
最后聊到DDD的现状与未来领域驱动设计。
这个概念呢最早是瑞克erevans这个大脑在领域驱动设计这本书里面提出来的这本书的出版时间是二零零三年。
所以我们认为二零零三年这本书的出版就标志着d滴滴的诞生。
最早在这本书诞生的时候呢，领域驱动设计，它的思想和理论其实并没有那么完善，包括领域驱动这本书的组织方式，也主要是以一些设计模式的方式组织起来的。
所以大家在读这本书的时候，会发现现在我们经常提到的一些概念，它里面其实并没有这本书本身呢可能也没有那么好懂。
在此后呢，很多大佬对领域驱动设计的理论和方法进行了完善和发展。
其中最重要的两个事件。
第一个是伦这位大佬在二零一三年出版了一本书，叫做实现领域驱动设计。
在这本书里面呢，问伦伦对领域驱动设计的思想进行了一个完善和丰富，包括他提出来领领域事件六边形架构啊以及及战略设计些些念念。
这些概念呢现在也是领域驱动设计里面一些比较重要的组成部分。
包括wonwinwericevans在给这本书写的续中呢，也对他的工作进行了一些称赞。
除此之外呢，还有一位大牛叫做arbettlebranddlini他在二零一三年提出来一种后面广为应用的一种建模方法，这种方法叫做事件风暴建模法。
按照这种建模法呢，我们在实践中可以更容易的应用DDD的理论。
所以他现在的影响力非常大，也是非常非常常用的一种建模方法。
所以这位大佬的工作也是非常重要的。
我们认为这三个事件是领域驱动设计发展中最重要的事件。
大家可以看到呢，它的发展其实是一个阶段性的发展也并没有那么快，但这也说明了领域驱动设计这个知识的半衰期呢，它其实是相对比较长的。
所以大家去学习它呢，我们可以说它的投入产出比是比较高的，不会像有一些技术，它可能出来几年就过时了OK上面这个曲线呢是滴滴滴在国内的一个搜索热度，其实在领域驱动设计这本书出版之后的一小段时间之内呢，领域驱动设计的思想其实并没有得到很大的重视。
但是随着后面SOA架构以及微服务的架构，尤其是微服务的架构的提出呢，大家发现领域驱动设计的理论和思想，它有着非常重要的现实意义。
它能够解决这些架构里面那些亟待解决的问题，包括像复杂性的控制啊，像服务划分啊这些问题。
所以在近十年呢领域驱动设计，它的关注度是在不断的提升的。
二零一八年达到了一个巅峰，目前还是一个峰神的状态。
此外呢，随着技术和业务的发展，国内的互联网公司也慢慢的认识到了领域驱动设计思想的重要性，他慢慢发现以往很重要的一些问题。
比如说像高并发呀，高性能啊这些问题随着技术的发展开始变得并没有那么难以解决。
而且呢在后续的业务发展中呢，可能在很多场景下也不是那么的重要，反倒是怎么样去控制软件的复杂性变成了一个更棘手的问题。
所以呢这些互联网巨头公司内部呢也逐渐对零售设计引起的重视，开始组织学习和应用，在面试过程中也会有所体现。
那下面这里呢只是列出了其中的一小部分。
ok说了这么多，让我们尝试对DDD的未来做一个预判。
我们知道互联网行业发展的下半段呢一个最重要的方向其实是产业互联网，包括现在广泛被提及的企业的数字化转型。
那么DDT思想呢，在这些方向上可以发挥比较重要的作用。
会这个世界正在变得越来越复杂。
同时呢，我们软件系统它面向的业务也在变得越来越复杂。
那么在么样去控制这些复杂性的正是领域驱动设计可以做的事情。
所以可以预见的是呢在未来领域驱动设计还会发挥越来越重要的作用。
那么在理论和工具方面呢，领域驱动设计，它的理论和方法还有工具也在不断的完善。
随着大家的实践越来越多，关注度越来越复呢，相信相关的建模方法和工具也会不断的进行完善。
比如我们知道一个很重要的建模方法是世界风暴建模法，而且后面呢还有一些其他方法会在不断的被提出来，包括二零一六年被提出来的sorrying。
这这建模法可能后面还会有一些不一样的方方法提出来，大家可以拭目以待。
此外呢近几年还有一些远程协作的建模工具出现，这也会帮助领域驱动设计的应用更加广泛。
但是有一点我们知道领域驱动设计在刚提出来的时候呢，大数据和allenai相关的技术还并没有那么成熟。
但是时至今日呢，大数据和AI在每一个软件系统中正在扮演着越来越重要的角色。
那么怎么样和大数据和AI进行结合，通过理论在业务系统中，对大数据和AI中的概念进行描述，这也是需要亟待解决的一个问题。
在这一点呢，我们这次的课程里面也会有所体现。
最后呢我们再大概介绍一下领域驱动设计的相关资料领域驱动设计最重要的两本书，一本是瑞erkevans写的这本领域驱动设计软件核心复杂性竞对之道。
这本书我可能有点难懂啊，另一本就是汪哥呢写的这本实现领域驱动设计，这本书比较偏实践一点。
此外呢还有一些其他的资料，包括领域驱动设计这本书，它还有一个精简版以及事件风暴建魔法，也有相关的资料，包括其他资料呢我们也会统一整理成一个清单发给大家方便大家学习OK在这节课呢我们学习了领域驱动设计的过去现在与未来通过这节课的学习，我们知道了领域驱动设计中比较重要的理论的发展意识，也知道了比较重要的几位大佬是谁？
这些在我们进行资料索引的时候呢，也会有一些作用。
并且呢我们了解了领域驱动设计的现状，也对他的未来做了一些预判，进一步明确了学习领域驱动设计的重要性OK这就是这节课的内容，谢谢大家。