这篇文章和《阿里技术专家详解DDD系列 第二弹 - 应用架构》隔了比较久，一方面是工作比较忙，另一方面是在讲Repository之前其实应该先讲Entity（实体）、Aggregate Root（聚合根）、Bounded Context（限界上下文）等概念。但在实际写的过程中，发现单纯讲Entity相关的东西会比较抽象，很难落地。所以本文被推倒重来，从Repository开始入手，先把可以落地的、能形成规范的东西先确定下来，最后再尝试落地Entity。这个当然也是我们可以在日常按照DDD重构时尝试的路径。

提前预告，接下来的一篇文章将覆盖Anti-Corruption Layer（防腐层）的逻辑，但是你会发现跟Repository模式的理念非常接近。等所有周边的东西都覆盖之后，再详细讲Entity也许会变得不那么抽象。

DDD 的宏观理念其实并不难懂，但是如同 REST 一样，DDD 也只是一个设计思想，缺少一套完整的规范，导致DDD新手落地困难。 我之前的架构篇主要从顶层设计往下看，从这一篇开始我希望能填补上一些 DDD 的代码落地规范，帮助同学在日常工作中落地 DDD 思想，并且希望能通过一整套规范，让不同的业务之间的同学能够更快的看懂、掌握对方的代码。但是规则是死的、人是活的，各位同学需要根据自己业务的实际情况去有选择的去落地规范，DDD 的规范不可能覆盖所有场景，但我希望能通过解释，让同学们了解 DDD 背后的一些思考和取舍。

DDD是一套完善的系统设计方法，可以帮助我们在系统设计的过程中缕清思路，规范流程，降低系统建设的复杂度，同时DDD的领域建模过程也是团队成员之间形成系统通用语言、建立良好沟通机制的过程。

在电商中台研发团队内部，很早之前就对DDD有过分享和讨论，近期我们在做购车发票总库的迁移工作，经过分析，借此项目做一次DDD的落地实践，在时间和人员投入上都比较适宜。本篇文章就对我们的整个实践过程做一个总结，与大家一起学习和提升。

为什么需要DDD 在回答这个问题之前，我们先看下大部分软件都会经历的发展过程：频繁的变更带来软件质量的下降。

笔者在react项目中尝试使用DDD方法论，为业务对象建模，以更好的理解和把握业务。本文从对业务的思考、react项目的特征出发，阐述笔者在项目中进行的前端DDD探索，以抛砖引玉，和读者一起思考前端DDD的理解和方法。

DDD指的是Domain-Driven Design 即领域驱动设计，DDD并不是关于技术的，而是关于讨论，聆听，理解和发现业务价值。DDD让我们的关注点向软件系统所提供的业务价值方向思考。 DDD最大的好处是：接触到需求第一步就是考虑领域模型，DDD让你首先考虑的是业务语言，而不是数据和行为。

领域驱动设计（Domain-Driven Design，简称 DDD）是一种软件开发设计思想，其旨在以领域为核心，让软件系统在实现时准确地基于对真实业务过程的建模，专注于业务问题域的需要。

DDD将软件系统设计分为了2个部分：战略设计和战术设计，战略设计用于提炼问题域并塑造应用程序的架构，战术设计用于帮助创建用于复杂有界上下文的有效模型。基于此，DDD强调专注于核心领域，通过协作对公共语言和知识进行提炼，并且持续致力于领域的知识提炼，让模型持续发展。

本文基于DDD思想，在携程国际火车票中台预订系统项目进行实践。

跟大多数互联网团队一样，B站也经历过“小步快跑，迭代试错”的阶段，但随着业务规模不断扩大，系统的功能也逐渐复杂，如何能够做到业务快速交付变成了摆在我们面前的又一个难题。最近我在负责我们会员购供应链业务的DDD改造，准备在这里把我们实践的方法以及遇到的问题“抖一抖，晒一晒”。

或许你也在经历着一个复杂度很高的，需求多变的系统，你也尝试寻找一个能够像“解药”一般的框架来让自己摆脱“泥潭”一般的现状，但是我想说软件行业是没有“银弹”的，任何不区分上下文地生搬硬套框架都很有可能遇到滑铁卢一般的惨败。因此做好业务知识储备，拥有独立的思辨力是对我们软件工程师的必备的要求。

文章主要分为三个部分，第一部分简单介绍一下DDD的一些概念，第二部分为结合业务的实操环节，第三部分为作者的心得分享。如果对DDD概念有过了解的同学，可以直接从第二部分看起。鉴于经验有限，本文的观点很多可能也只是一家之言，所以我也比较希望读者们能够带着批判的眼光来看这篇文章，在此也非常希望大家能够一起学习探讨。

微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方。换句话说，确定了业务边界和应用边界，这个困境也就迎刃而解了。

供应链商品域DDD实践时间不长，在实践过程也碰到了不少问题，有些找到了答案，有些还是在探索中。

聚合模式是 DDD 的模式结构中较为难于理解的一个，也是 DDD 学习曲线中的一个关键障碍。合理地设计聚合，能清晰地表述业务一致性，也更容易带来清晰的实现，设计不合理的聚合，甚至在设计中没有聚合的概念，则相反。

聚合的概念并不复杂。本文希望能回到聚合的本质，对聚合的定义和实操给出一些有价值的建议。

领域驱动设计不是新鲜的概念，自2004年由建模大师Eric Evans发表他最具影响力的书籍《领域驱动设计—软件核心复杂性应对之道》至今已有十六年1·时间，一直以来不曾大行其道，直到IT行业内掀起微服务的狂潮，技术界才重新审视和意识到领域驱动设计的价值。不能说微服务拯救了领域驱动设计，但是确实因为微服务，让领域驱动设计又重新焕发了青春。DDD是一个非常庞大的建模和设计体系。

在过去一年里我们团队做了大量的老系统重构和迁移，其中有大量的代码属于流水账代码，通常能看到是开发在对外的API接口里直接写业务逻辑代码，或者在一个服务里大量的堆接口，导致业务逻辑实际无法收敛，接口复用性比较差。所以这讲主要想系统性的解释一下如何通过DDD的重构，将原有的流水账代码改造为逻辑清晰、职责分明的模块。

毫无疑问地说，作为测试是一定要熟悉业务的。实践中，读懂业务代码似乎并不是一件那么一帆风顺的事情，所以在此我总结了一些有可能阻碍读懂代码的小知识点进行分享。

好的集群架构应该满足，一是可以避免单点故障；二是可以水平扩展；三是能实现负载均衡。

关于对DDD的理解，每个人都可以是不同的，并且依据不同的理解所写的业务框架也是不同的，只要在一定的范围内能够逻辑自洽，那是没问题的。在启动DDD改造前，组内也做过一些分享，制定了一些规范，本文就是对组内这些规范的一个总结。

复杂业务系统长期迭代，难免会逐渐腐化，如何治理腐化，并设计出能够延缓腐化，保持长期高效能的方案是一个开发同学难免要遇到的问题，本文旨在介绍一套基于DDD的落地实施方案，提供另外一种解决问题的思路。