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

本文旨在介绍DDD领域驱动如何在复杂业务进行设计落地以及技术代码落地，提供领域驱动的设计思路与实施经验干货。

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

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

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

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

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

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

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

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

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

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

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

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

本文阐述了一种将分层设计和DDD领域设计思想应用于微服务体系架构的方案实践，也是个人的最佳实践。对于大部分互联网公司来说，我们主张将其Web服务架构分为五层：基础设施层、领域服务层、应用服务层、网关层和用户界面层（表示层）。领域服务层和应用服务层均可以采用微服务设计进行拆分，其中领域服务层将按照DDD领域设计进行领域划分，设计为一个个领域模块微服务，每个微服务高度内聚，仅关注自己的业务，领域服务间通过接口调用进行松耦合。这种设计方案可以大大简化大系统，并且在后期的维护中优势会日渐凸显，然而把大系统分而治之拆成微服务同时也对架构师和开发人员提出了更高的要求。第2部分介绍了相关背景，接着第3部分探讨了分层设计以及每一层的功能，第4部分结合微服务和DDD对领域服务层进行服务模块划分和设计。第5部分则就分层设计和DDD领域设计中常见的问题进行了整理。

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

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

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