一：DDD的历史
①：领域驱动设计(简称DDD)历史悠久。
②：领域驱动设计最初由Eric Evans提出，2004年著名建模专家eric evans（埃里克埃文斯)发表的她最具影响力的书籍：<<domain-driven design-tackling complexity in the heart of software>>（中文译名：领域驱动设计一软件核心复杂性应对之道)一书。标志着DDD这种设计和架构方法的诞生。
③：传统的数据驱动架构设计：我们日常的开发中，经常针对一些功能点争论：这个功能不应该我改，应该是你那边改。最终被妥协改了之后都改不明白为什么这个功能要在自己这边改。而领域驱动设计DDD也许在这个时候能够帮助你做到清晰的划分。
④：多年以来一直停留在理念阶段，然而，真正能实现并且落地的项目和公司少之又少。近年来，包括阿里在内的很多大厂，都在大力推行DDD的设计方法。
⑤：它主要可以帮助我们解决传统单体式，集中式，大泥球架构难以快速响应业务需求落地的问题，并且针对中台和微服务盛行的场景做出指导。
⑥：DDD为我们提供的架构设计的方法论，既面向技术也要面向业务，从业务的角度，自顶向下来把握设计方案。
二：DDD的巨大价值
①：统一思想：统一项目各方业务，产品，开发对问题的认知，明确组织当中产品，业务，架构，开发的角色和如何配合。通过统一的语言，明确的定义。统一方方面面的理解误差和理解分歧。DDD工具链能够帮助进一步强化能力逻辑的表达，借助DDD可视化流程构建专业知识库，能够快速提升产品和技术，技术和技术之间的沟通效率。帮助开发同学快速，直观的了解业务，进而提高技术同学对业务有快速/全局了解，反向帮助开发能够方便把握细节，降低反复，返工，甚至推导重来的概率。
②：动态建模：需求是不断变化的，传统HLD,LLD建模的核心思想是静态建模，缺乏有效的动态建模方法论和工具。DDD通过从领域事件，领域命令触发对领域对象进行建模，可以真实的反映这些变化，更好的通过边界划分将复杂的业务领域简单化，将隐藏的业务显性化，隐式流程显性化，隐式字段显性化。帮助我们设计出清晰的领域边界，准确的业务流程，可以很容易地实现业务和技术统一的架构演进。
③：拉通“断层”：传统的需求常常是一句话需求，模型设计常常是工程师负责，工程师的设计路径是库表驱动+界面驱动，结合常规MVC三层架构进行自底向上的设计，完美的实现了业务人员和编码人员断层，需求和开发隔离的目标。DDD拉通了业务和编码，对常规MVC开发模式做了一个反转，以业务为主导，自顶向下的进行领域模型设计，拉通业务和编码之间的巨大断层，使得代码更能反馈业务，反哺业务，提升代码逻辑的准确度和生命值。
业务人员和编码人员隔离的原因：轻设计，重编码。一句话需求，敏捷迭代，很容易把代码弄得杂乱无章，混乱不堪。
④：彻底“反腐”：首先是领域模型与数据模型分离，用领域模型来界定哪些需求在什么地方实现，保持结构清晰，隔离数据模型，存储模型的变化和腐败。除了数据模型，咱们应用中有许多容易腐败的操作，比如直接的外部依赖，例如：Mybatis的Mapper类，HttpClient注入，RocketMQ的监听，缓存的直接操作等。DDD通过防腐层的架构设计，实现业务代码的彻底防腐败。
简单来说：
1：反腐败设计：从一半业务+一半技术，提升到业务代码和基础设施解耦。
2：反腐败设计，使得领域代码更有业务纯度。
同时，DDD帮助沉淀各领域的业务，标准化的流程链路，各领域间无耦合，沉淀的领域能力能够很好的复用。粗粒度的应用能力能基于细粒度领域能力去构建，构建好的能力可以在其他场景直接复用，提高开发效率，最终提升领域代码的生命力，复用力。
⑤：提升“测维扩”能力：可维护性=当依赖变化时，有多少代码需要随之改变，传统的MVC三层架构，面临各种库升级，依赖服务升级，中间件升级，jar包冲突，微服务框架升级，存储扩容升级等依赖变化工作，需要从上到下，每一层的代码都要动，可维护性差。
可扩展性=做新需求或改逻辑时，需要新增/修改多少代码，在库表驱动开发，库表驱动的架构开发流程中，一般做第一个需求都非常的快，但是由于代码复用性低，越做到后面，做第N个需求时需要的时间很有可能呈指数级上升的，绝大部分时间花费在老功能的重构和兼容上，最终你的创新速度会跌为0，促使老应用被推翻重构。
可测试性=运行每个测试用例所花费的时间*每个需求所需要增加的测试用例数量。在库表驱动开发，库表驱动架构的开发流程中，由于设施搭建困难，用例笨重运行耗时长，业务耦合度高用例爆炸等原因，业务代码很难有比较好的测试覆盖，而绝大部分的业务代码在上线前的测试属于人肉的集成测试，低测试率导致我们对代码质量很难有把握，容易错过边界条件，异常case只有线上爆发了才被动发现。
最终这个应用变成了一个不敢升级，不敢部署，不敢写新功能，并且随时会爆发的炸弹，终有一天会给你带来惊喜。
DDD根本上解决上面的问题，提升“测维扩”能力。
⑥：降本增效：以爱奇艺DDD落地案例为例，其会员业务部门在打赏业务中实践DDD后，取得了以下显著成果：新需求接入开发成本节约20%，更换底层中间件开发成本节约20%，项目熟悉成本节约30%(对DDD有基本了解为前提);单测开发成本指数级降低；上线风险，成本降低。
