本文是作者结合2019年07月12日在ArchSummit全球架构师峰会DDD（领域驱动设计）落地探索专场做的主题分享：《DDD战略建模在重构业务系统中的实践》的内容整理而成。

DDD作为架构设计思想帮助微服务控制规模复杂度，那它是怎么做到的呢？

随着历史业务不断迭代和业务场景越来越复杂，携程用车、租车（简称两车）面临历史技术债和系统复杂度越来越高带来的理解、维护、迭代困难等问题，我们开始寻求如何更有效的降低复杂度和提升效率的方法。

本文描述了两车如何利用DDD（Domain-driven Design，领域驱动设计）方法论降低系统复杂度以及在重构历史系统中的取舍和思考。对于复杂业务场景下的领域驱动设计具有借鉴意义。。

从我们作为业务开发主要的职责深入到DDD的本质是什么？复杂度应处理？规范设计怎么做？本文将全方位为大家解答。

如果要在前端业务工程上深度应用领域驱动设计的思想来实践，最好考虑好这几个前提......

DDD（Domain-Driven Design）：领域驱动设计。首先需要了解，所谓的「领域」，其实不仅仅在于程序表现形式，更适合说是对特定业务的描述，通常由该业务的垂直协作方共同确定，比如产品需求、系统架构、程序代码，由一群“专业的”人承接，这意味着其中的每一个人，可能都是该「领域」内的专家，而「领域模型」成了他们之间的「通用语言」，或者说，「领域知识」让彼此能够坐在一起讨论问题，再换句话说，产品也可以使用此通用语言来“组织代码”。这也是 DDD 的战略意义。

当我们在学习DDD的过程中，感觉学而不得的时候，可能会问：我们还要学么？

探究CQRS为什么广泛应用于DDD项目中以及如何落地实现CQRS框架。

本文主要讲述了战略层面的DDD原则，相对来说较为抽象，但这是最考验内功、最不可忽视的环节。

这是“领域驱动设计实践之路”系列的第三篇文章，分析了如何设计聚合。

DDD是一套思想、方法论。 种类繁多的元模型和概念。其本质都是指导思想对应的解决方案“之一”，初学者容易被表象所困。应始终清醒保持认知“DDD各种元模型都是为解决实际开发中某类问题而起”,在接触各类元模型时应结合自身业务面临问题来求证。

值对象是实体的一个重要组成部分，如何正确使用值对象，也是 DDD领域驱动设计的一个难题。本文将介绍值对象的概念与使用方法。

最近几年，微服务拆分大行其道，在业务越来越复杂的情况下，许多业务纷纷抛弃了传统单体架构，拥抱微服务。但随着微服务的拆分结束，大家又发现了新的问题，比如服务间逻辑复杂，运维复杂性变高，微服务架构变得越来越难以管理，最终演化成大泥球架构。

而本文主要介绍如何通过DDD对微服务进行拆分，首先介绍了什么是DDD，通过从分析DDD的优势，到如何通过DDD进行业务拆分，并且在最后通过代码样例的方式，深入浅出的为读者介绍了DDD代码的核心实现。帮助大家进一步的了解DDD应该如何落地。

本文介绍企微助手对代码 DDD 架构的升级。

1776 年亚当斯密发表《国富论》，标志着经济学的诞生。2004 年，一本名为《领域驱动设计·软件核心复杂性应对之道》的书问世，开辟了软件开发的一个新流派：领域驱动设计。看完这本书，十个人有九个人的感觉都是：似懂非懂，若有所得，掩卷长思，一无所得，我个人的感觉同样如此。出于兴趣，多年来仔细研读了几十本相关书籍，融汇贯通，逐步形成了自己的一套看法，本文就和各位分享一下。

冯友兰治哲学，提出“照着讲”和“接着讲”的方法论。近两年，我断断续续梳理出关于领域驱动设计的两个 PPT：《领域驱动设计》和《领域驱动设计四论》。前者的内容主要是关于 DDD 经典著作的读书笔记，可视为照着讲，以证明自己学有所本，讲的不是野狐禅；后者则是在继承的基础上所做的创新阐释，可视为接着讲，发前人之未发。本文重点围绕《四论》展开，从四个方面梳理出 DDD 的整个逻辑脉络。

曾见郭象注庄子，却是庄子注郭象。一些领域驱动设计的拥趸们，如果看到本文的论述和自己的理解相左，丝毫不用奇怪，本文阐述的四论，不是我注六经，而是六经注我。

本文大部分内容都在众多前辈理论基础上，从一个崭新的领域视觉开始探索，并结合自己的实践感悟进行细致的解析。