领域驱动设计（DDD）理论启示.pdfVIP

领域驱动设计理论篇 过去几年通天塔一直处于快速的业务能力建设和架构完善的阶段，以应对不断增长的业务需求和容 量、高可用等技术需求，现在通天塔平台已经能满足集团主站的大部分活动、频道搭建和运营能力，主流 程的新需求越来越少，个性化需求和非标准化流程的数据源和服务接入的需求越来越多 ，有些甚至是京东 零售体系外的，同时通天塔技术和产品也在积极主动寻求变化和创新，这些因素结合在一起驱动通天塔孵 化出了一个以技术为导向的项目：通天塔积木，旨在构建一个基于完全开放的前端 SDK 和后端数据源服 务、高度灵活和强大的积木画布、能够快速移植和部署到任何第三方 IT 环境的活动搭建解决方案，这套方 案的初衷和设计理念也契合了京东国际化赋能和 PaaS 化的战略。目前通天塔积木已经取得阶段性成果， 已开始赋能京东国内和国际站，但如何应对异常复杂的积木业务逻辑和不可预知的业务变化，构建业务和 底层技术基础实施的完全解耦的系统，一直是我们面对的巨大挑战。也是时候从更高视角来看清问题和源 头，思考一种能应对和控制业务复杂度、具备强扩展性和弹性的解决方案。纵观我们的目标，DDD 这个 词不知不觉映入了我的眼帘。 2004 年著名建模专家 Eric Evans 发表了他最具影响力的书籍《Domain-Driven Design –Tackling Complexity in the Heart of Software》（领域驱动设计—软件核心复杂性应对之道），书中反复强调领 域通用语言(Ubiquitous Language)的重要性，全面阐述了 DDD 战略设计到战术设计的方法论和实践。 让软件研发所有参与者围绕着一个统一和一致的领域模型建模和设计 ，分析模型和设计模型不在割裂，并 引出了以领域为核心的分层架构 ，有效地分离业务和技术复杂度，使得领域层的代码和领域模型保持高度 一致。在战术上提供了诸多元模式帮助构建职责清晰、内聚和高维护性和可扩展性的代码。 领域驱动设计不是新鲜的概念，至今已有十六年时间，一直来不曾大行其道，直到 IT 行业内掀起微服 务的狂潮，技术界才重新审视和意识到领域驱动设计的价值。不能说微服务拯救了领域驱动设计，但确实 是微服务，让领域驱动设计又重新焕发了青春。DDD 是一个非常庞大的建模和设计体系，这篇文章只在 理论和概念上阐述 DDD 的价值、方法和架构，欢迎任何的问题指正和补充。 1 ，DDD 价值 1.1 ，应对复杂业务 引起软件系统复杂度的主要因素是需求，软件系统需求又可以分两个方面：业务需求和技术需求。我 们分析系统的复杂度时就可以从业务复杂度和技术复杂度这两个维度出发。 业务复杂度跟系统的业务需求规模和需求之间的关系层级有直接关系，需求的数量和关系的层级决定 代码的规模和逻辑循环或递归的层级，系统的需求数量越大，需求之间的关系越复杂，系统的业务复杂度 就越大。John Ousterhout 的著作《A Philosophy of Software Design》从认知的负担和开发工作量的 角度来定义软件系统的复杂度，并给出了一个复杂度公式： 子模块的复杂度（cp ）乘以该模块对应的开发时间权重值（tp ），累加后得到系统的整体复杂度（C ）。可 以看到系统整体的复杂度并不简单等于所有子模块复杂度的累加，还要考虑该模块的开发维护所花费的时 间在整体时间中的权重占比（tp ），这个权重比就跟模块划分是否内聚、设计是否优雅有直接关系。 技术复杂度则来自于对软件系统运行的质量需求，包括安全、高性能、高并发、高可用和高扩展性。 系统安全性要求对访问进行控制，无论是加密还是认证和授权，都需要为整个系统架构添加额外的间接 层。不仅对访问的低延迟产生影响，还极大提升了系统代码复杂度 ；为了让后端系统能具备高扩展性和弹 性，要求所有系统的设计必须是无状态的 ；为了提升用户端访问体验，后端需要增添离线任务对数据加 工、异构、预热、预缓存，以实现用空间换时间，降低实时接口的逻辑复杂度来降低请求的延迟。然而最 让开发者更抓狂的是这些技术需求彼此又是相互影响甚至相互矛盾，在一些复杂流程并要求高响应的业务 场景，如下单、秒杀等，会将一个同步的访问请求拆分为多级步骤的异步请求，再通过引入消息中间件对 这些请求进行整合和分散处理，这种分离一方面增加了系统架构的复杂性，另一方面也因为引入了更多的 资源，使