之乎者也·的博客

就像我们根据反复经验形成一套模式一样，领域模型也会形成一套模式，其中包括实体、值对象、模块和领域服务。

前段时间在面试的时候，面试官问到：你是如何将DDD（领域驱动设计）应用到基础设施的？我很惊讶，终于有人问我这个问题了。在过去从事基础设施（DevOps、SRE、运维）的5年里，我经常说起DDD是一种思维模式，可以应用到任何的领域，包括基础设施的设计。但是，从来没有人像这位面试官问起我具体的做法。为什么没有人问？原因大概是这两个概念通常是不会放在一起的。大多数开发不会深入理解基础设施的设计，而大多数从事基础设施设计的人是不会接触到DDD。而且，开发人员对于DDD的理解，也仅局限于用它开发业务系统。

DDD是领域驱动设计的简写。前段时间听群友说行业里少有DDD的代码案例，进而对DDD没有一个感性的认识。我想这是行业里普遍存在的现象吧。所以，就有了写此文的想法。文章标题说的是“同事的代码”，其实只是为了让此文更具传播，没别的意思。本文开篇介绍了行业里比较普遍的代码风格，接着，我采用DDD风格对其进行修改。我无意说服读者要按照我认为的DDD的风格来写代码，只是想告诉大家，这个世界上，还存在另一种代码风格。本文虽是以Java语言为案例演示，也希望对其它语言的读者朋友有帮助。

我们生活中都听说了DDD，也了解了DDD，那么怎么将一个新项目从头开始按照DDD的过程进行划分与架构设计呢？目前领域驱动设计是目前比较流行的一种架构设计，只需要按照领域驱动设计的四重边界进行架构设计，就能够很好的对各个领域解耦，对后期的业务垂直扩展、功能的水平扩展提供了良好的基础。

本文主要对DDD项目落地的一些经验进行了分享，作为一名一线研发如果领导要求使用DDD做项目开发，对于研发而言其实最重要的就是要明白我写一个功能到底怎么写，到底把类放在哪个模块才不会到导致代码腐坏，本文则针对这方面提出了部分建议。

在常规操作下，会在每一个用到电话号码的方法入口都会写大量的这种校验代码和判断代码，尽管我们可以将它的校验和获取区号编码抽离成util类（实际上大多数工程中都是这么做的），但这种方式治标不治本。动态方案的缺陷在于大量的反射调用，性能比较差，内存占用多，不适合特别高并发的应用场景。虽然Assembler/Converter是非常好用的对象，但是当业务复杂时，手写Assembler/Converter是一件耗时且容易出bug的事情，所以业界会有多种Bean Mapping的解决方案，从本质上分为动态和静态映射。

但是、请注意、“菜”不可以“炒菜”，因为“炒菜”的时候，“菜”还没有出现呢，“菜”不是自己的上帝，“菜”需要被做出来，所以“菜”被做出来之前是没有“菜”的，这是个时间上的概念，不要错把“炒菜”的能力放在“菜”的身上。领域上下游关系指的是影响力的关系，上游影响下游，影响力分为“逻辑影响”和“数据影响”，一般说来我们更应该关注“数据影响”，所以领域上下游关系是一种数据流向的限定，是业务发生的顺序限定，用于规定该领域所使用的数据，是下游领域依赖上游领域“准备就绪”的体现。

编码时，要特别注意各层间应有各自的语义。试想，业务逻辑和技术细节糅杂在一起，Service作为上帝类包揽一切情况：先几行check 检验，再几行是 convert 转换，紧跟是业务逻辑处理，中间抑或要通过 RPC 或 DAO 获取更多数据，拿到数据后，又是几行 convert，再接上一段业务逻辑代码，然后落库，发消息…特殊，步步为营计，可在基础设施层中单拎出demo-infrastructure-po模块，且领域层中demo-domian-model对其依赖，便于以后PO从领域层中再剥离出来。

领域驱动设计，Domain-Driven Design，简称 DDD，是一种软件设计方法论，它强调以业务领域为核心来构建软件架构，DDD 由 Eric Evans 在其 2003 年的同名书籍中首次提出并进行了系统性地阐述，自此在软件研发领域中产生了广泛的影响。DDD 的出现是为了解决复杂业务领域的软件建模问题，随着企业应用的复杂性和规模的不断增长，传统的以数据为中心或者以技术为中心的设计方法往往难以应对，DDD 通过引入领域模型、通用语言、限界上下文等概念，帮助开发团队更好地理解和应对业务领域的复杂性。

为每个子领域定义限界上下文（bounded context），限界上下文是一个清晰定义了领域模型的边界的范围。在限界上下文内，领域模型的概念是一致的，但不同限界上下文之间可以有不同的模型和语言。界限上下文，基本可以对应到 落地层面的 微服务。这就是 DDD 建模和 微服务架构， 能够成为孪生兄弟、 天然统一的原因。DDD 战略设计的第一步就是统一语言，也叫通用语言（UBIQUITOUS LANGUAGE），用于定义上下文 的含义。

在动态且不断变化的技术世界中构建满足企业和用户的需求和期望的软件可能具有挑战性。软件公司逐渐需要一种可行的方式来让业务和产品团队之间的沟通更加透明。领域驱动设计（DDD）方法通过促进对主题的深刻理解以及开发人员和业务专家之间的持续协作来帮助解决这个问题。事实上，开发人员通过不断的沟通，对底层领域和业务规则有了更深入的了解。同时，利益相关者可以更好地了解技术能力和限制。

在本文中，我们采用了分治的思想，从抽象到具体阐述了DDD在互联网真实业务系统中的实践。通过领域驱动设计这个强大的武器，我们将系统解构的更加合理。但值得注意的是，如果你面临的系统很简单或者做一些SmartUI之类，那么你不一定需要DDD。尽管本文对贫血模型、演进式设计提出了些许看法，但它们在特定范围和具体场景下会更高效。读者需要针对自己的实际情况，做一定取舍，适合自己的才是最好的。本篇通过DDD来讲述软件设计的术与器，本质是为了高内聚低耦合，紧靠本质，按自己的理解和团队情况来实践DDD即可。

通过前两步的抽象，形成了所谓的领域模型与领域服务。业务层业务层我想聊聊model到dto的转换，从领域层接收到的数据为model，然而我希望传给应用层的是dto。为何不能直接将领域对象用于数据传递？领域对象更注重领域，而DTO更注重数据。传输对象DTO本身并不是业务对象。数据传输对象是根据UI的需求进行设计的，而不是根据领域对象进行设计的。避免直接将领域对象的行为暴露给表现层。同时对外的DTO不应感知领域的变化，无论内部如何变化，对外都不能直接耦合，应该经过convertor转化后保持一致。

其实很简单，我们需要一个载体，去把思考的过程沉淀下来，等到产品经理来找我们加需求评估影响范围的时候，新人入职给他讲解业务的时候，通过这个载体就能直观地呈现出来，这就是DDD设计呈现的魅力所在。如果业务经过战略设计合理去划分，每个业务的业务边界会显得特别清晰，即使我们的代码没有使用DDD的思想去完成搭建，即使我们还是使用传统的MVC架构，也不会影响业务正常运作，业务的通用语言有它的业务边界，我们不大可能用一个简单的术语没有歧义地去描述一个复杂的业务领域，BC就是用来细分领域，从而定义通用语言所在的边界。

DDD 全称 Domain-Driven Design，中文叫领域驱动设计，是一套应对复杂软件系统分析和设计的面向对象建模方法论。它由Eric Evans于2003年提出，但一开始不愠不火。直到MartinFowler于2014年发表论文《Microservices》，引起大家对微服务的关注，至此DDD重新慢慢的回到了大众的视野中。

相较于常规的MVC架构，DDD更抽象、更难以理解，各个开发者对DDD的解释也不尽相同。那么哪种设计方式才更好？在学习时如何知道哪种DDD更正统，没有被别人带歪？本文尝试使用“DDD as Code”的概念，即用DSL代码方式来描述DDD，统一DDD的设计思想，通过案例详细介绍如何基于ContextMapper来完成一个项目基于DDD DSL的表达，并分享现实中DDD的设计流程和微服务的关系。网上有非常多关于DDD的文章，这当然是好事情，大家都想掌握好的设计方法来解决软件开发中的问题。

通过使用DDD架构，可以更好地理解业务需求、优化系统架构、提高系统性能和可伸缩性，帮助设计出高内聚低耦合的复杂应用系统，并且能够更好地应对系统变化。但DDD并不是适用于所有场景的解决方案，它需要根据具体情况进行分析，根据业务需求和技术特点选择合适的架构模式，并结合实际情况进行设计和实现。

此外，在库存扣减操作中还需要存储库存扣减记录，一旦用户取消订单或退货时，可以根据扣减记录返还相应的库存数量。库存是一个非常复杂的概念，涉及在仓库存，计划库存，渠道库存等多个领域实体，在我们《DailyMart微服务&DDD》实战中，主要关注的是在仓库存模型。用户付款时：update 扣减记录行，状态为扣减状态，同时update库存行(减少预扣库存，增加占用库存，wq-,oq+)；根据上述定义，对于一个商品，可售库存数量与预扣库存数量之间的关系是：可售库存（SQ） + 预扣库存（WQ） = 可用库存。

在阿里两年，我感受很深的一个点是，我们不能持续交付不断演进的复杂软件，所以有1.0、2.0、3.0很多的版本，1.0搞不下去了，开始2.0，2.0也搞不下去了，开始3.0，不断循环。系统结构复杂，因为应对高并发、高稳定性等，功能性代码与非功能性代码混合，如业务代码混杂着各种兜底逻辑、灰度逻辑、重试等等，100行代码，可能业务代码不到30行。在各种文档和平时沟通中，保持概念统一，特别提一下，做一个中文对照， 把概念和代码连接起来，在代码做到概念名称统一，减少混淆。关注点是分离的，可以分而治之，可测试性好。

从数据识别来源上区分，可以分为AI识别出来的，词典规则匹配出来的，还可能是业务方传递进来的。在实际的业务环境中，我们的领域模型或多或少的都有一定的“特殊性”，如果100%的要符合DDD规范可能成本会比较高，所以最主要的是理解DDD思想，最终选择合适自身业务的方案。贫血模型：通俗来说，就是domain object只有属性的getter/setter方法的纯数据类，业务逻辑和应用逻辑都放到服务层中，这种模型下的domain object被Martin Fowler称之为“贫血的domain object”。

虽然经典架构更直观，但鉴于COLA对领域模型为中心的设计，保证领域层的独立性，最终促成我们采用COLA架构作为统一的模版，和六边形架构类似，它的核心理念是：应用是通过端口与外部进行交互的，内部业务逻辑（应用层和领域模型）与外部资源（外部服务，数据库资源、消息中间件等）相互隔离，仅通过适配器进行交互。通过将核心业务逻辑下沉内聚，降低调用方的业务复杂度，防范逻辑腐化。在完成现有业务的改造后，依然会面临业务变更和新增业务的挑战，系统的模型也不是一成不变的，我们也依然需要对系统进行不断的自我更新以适应业务的发展。

解决日常排查问题的痛点。为了能有效的解决上面的问题，我们开始了基于 DDD 思想的重构，核心是：产品和技术坐在一起，讨论业务玩法并达成共识，借助“域”的概念，搭建新的模型完成对业务进行重塑，既能满足已有核心业务，又能为未来业务发展做好规划。例如：免房本是流量置换来的底价为0的资源，免房团队如果按照代理商的逻辑给到报价，报价就不需要处理，但免房团队需要考虑售出量和免房的收益，就提出要比最低底价的代理商低1块钱，而其他代理商的底价是用户请求时实时计算出来的，为了实现这个逻辑，就要侵入报价的计算逻辑。

在传统的开发模式中，不同环节的人员经常会出现对于同一对象的叫法不一致、定义不一致的现象，这在一定程度上也造成了大家对于系统理解的偏差，而在DDD模式中，提出了通用语言的概念，参与其中的所有成员在系统生命周期内均采用简单清晰明了的通用语言进行交流，通用语言成为团队内外部系统交流的统一语言，既减少了信息的失真, 又确保了大家在同一领域知识体系内交流的便利性、理解的一致性。领域层模块，定义了发票领域的实体、值对象、发票事件、发票领域服务以及仓储层接口，同时包含了创建领域实体的工厂类。

去年我们在重构项目中落地了DDD，当时花了点时间研究了下阿里巴巴大淘宝技术发布的《阿里技术专家详解DDD系列》，其中第三讲《阿里技术专家详解DDD系列 第三讲 - Repository模式》中提到了一项技术--变更追踪。当数据从DB里取出来后，在内存中保存一份snapshot，然后在数据写入时和snapshot比较。常见的实现如Hibernate。当数据从DB里取出来后，通过weaving的方式将所有setter都增加一个切面来判断setter是否被调用以及值是否变更，如果变更则标记为Dirty。

Presenter 与 View 为一对一的方式，就像一块蛋糕（View），指派给一个厨师（Presenter）去制作，但是厨师一个人需要做的事情太多，他需要亲自加工食材（Model），再将这些材料一一装饰在蛋糕上面，如图 4 所示。基于 DDD 的思想，新闻客户端实现了一套包含 UseCase 的基础框架，划分出了领域模型，由于视频详情页由多 Fragment 组成，技术团队还加入了共享变量层，使拥有统一生命周期的组件之间能解耦传递数据，重构后的视频详情页整体架构如图 8 所示。

同时，我们的表格也是一个包含大量字段的订单大表。当业务规模庞大到一定程度，编排本身就富含了业务逻辑（除此之外，应用服务在稳定性、性能方面所做的措施也希望统一起来，而非散落各处），那么此时应用服务对于外部来说是一个领域服务，整体看起来则是一个独立的限界上下文。在抽奖上下文中，我们通过抽奖(DrawLottery)这个聚合根来控制抽奖行为，可以看到，一个抽奖包括了抽奖ID（LotteryId）以及多个奖池（AwardPool），而一个奖池针对一个特定的用户群体（UserGroup）设置了多个奖品（Award）

限界上下文是语义和语境的边界。在问题空间，统一语言构成了团队对领域概念的统一表达，子领域形成了领域概念之间的边界。而在解空间，限界上下文可以看作是统一语言+子领域的结合体，统一语言在限界上下文内才具有明确的业务含义。以电商购物场景为例。在进行商品下单后，系统会生成一个订单；在用户付款完成后，系统也会生成一个订单；到了物流派送流程，系统还会生成一个订单。虽然这三个步骤中的领域概念都叫订单，但是他们的关注点/职责却不同：商品订单关注的是商品详情，支付订单关注的是支付金额和分润情况，物流订单关注的是收货地址。

视频会员部门正在推进一个领域驱动的项目，期望运用 DDD 的一些理论，对会员技术体系的进行全面梳理。复杂度：业务复杂性（包括播放、购买、活动、内容展示、内容互动等全场景），以及技术复杂性（如业务规则、模块繁多、高并发、信息安全等），需要全面考虑。跨部门合作：目前的会员内容体系，涉及会员、直播中台、腾讯云、安平审核等多个部门，是一个典型的跨部门合作项目。体系梳理：会员业务涵盖内容展示、内容互动、内容合作和内容创新四个方面。领域模型：本文将重点借助领域图，将整个会员内容体系以直观的方式展现出来。

开宗明义，DDD 是一种技术方法论，不是某种具体的技术架构，也不是某种编程框架层面的东西。如果你面临的任务是把一个经过多年开发迭代从而变的异常繁杂的系统，重新梳理重构为一个结构合理、职责清晰的新系统，那么 DDD 作为一种技术方法论可以一展身手。DDD 为复杂度而生有同学找到我说，在他看来 DDD 是解决效率问题的，我说 DDD 解决的是复杂度问题。复杂度来源于两个方面：技术复杂度（例如安全、高性能、高并发、高可用性等）和业务复杂度。

在介绍 DDD 相关概念前，我们先探讨一下为何要采用领域驱动设计。在非领域驱动设计的项目中，我们通常会先进行数据库表的设计，然后根据表结构推导出相应的实体对象。这些实体对象仅仅是数据的载体，缺乏实际的行为。在这种设计模式下，业务流程实现仍属于面向过程，以数据为中心的过程式思想，开发过程可以理解为对数据进行移动、处理和实现的过程。而如果采用 DDD 的思想去设计，我们将构建一个基于面向对象原则的系统。

携程用车订单业务包括接送机、包车、打车等产线，涉及订单状态管理、支付状态管理、供应商订单状态管理、履约状态管理等功能。履约状态关乎司机相关状态，完成订单需结清额外费用。携程租车订单业务涵盖订单状态管理、支付状态管理、押金扣除记录、供应商订单状态管理、履约状态管理等功能。履约状态主要涉及取还车相关状态。通过划分上下文和明确职责，各个领域负责自己的数据和领域知识。这样一来，订单不再涉及这些字段，而是由数据写入的业务方负责维护。因此，在后续与订单无关的业务逻辑发生变化时，订单无需进行修改。

领域驱动设计（Domain-Driven Design），简称 DDD，并非一种框架或具体的架构设计，而是一种架构设计思想。其代表性著作便是“领域驱动设计之父”Eric Evans 的经典书籍《领域驱动设计》。DDD的核心目标是通过各种实用方法和技巧提炼出具有体现问题实质的领域模型，并通过保护和组织模型协作来解决领域问题，从而掌控问题领域本身的复杂性，也就是为什么DDD会被认为是软件核心复杂性的应对之道。

现在对于一个后端开发工程师来说，微服务，DDD都是挂在嘴边的东西，感觉大家接触到多，也了解的多。然而，个人对微服务架构的理解却如同我小时候读《三国演义》，随着年龄和经验的增长，感受也各不相同。微服务对于开发人员而言，如同千面镜，每个人看到的风景都独具特色。基于此，我想结合自己的业务实践，分享一下在微服务架构实践过程中的心路历程。在笔者看来，微服务架构并没有一个准确的定义，但他会有很多特征，通过描述他的特征用来把控它是什么。

观看视频时，选择明星、礼物进行打赏；打赏后屏幕有气泡提示；打赏数据在排行榜进行显示；累计一定的打赏获得某种奖励。

首先，我们来回顾一下著名的康威定律：设计系统的组织，其产生的设计等同于组织之内、 组织之间的沟通结构。康威定律成立说明组织架构与系统之间必须匹配，但未强调合理。接下来，我们再看一下DDD 中的康威定律，它的核心观点是系统架构主导组织架构。由于DDD立足于业务领域，回归业务本质，因此其与业务的契合度较高，更易于实现合理性。有些人可能会疑惑：如何划分团队才能与业务紧密结合？其实，这个问题的本质在于让DDD中的制约因素成为需要改变的目标。

上列四张图简单展示了去哪儿网本次重构的主题，也是酒店基础信息部所负责的业务。列表页：用户打开 APP，输入目的地和入住时间，点击搜索，便会转到列表页，展现搜索地点的所有酒店列表信息。详情页：点击希望入住的酒店，即可进入详情页。酒店Info：点击酒店名字，则可进入酒店Info页。进订页：用户决定预定酒店房间后，就跳转到进订页。组织资源是否集中在了核心业务领域；是否能用统一语言沟通描述业务，体现在需求评审、站会等有关会议的效率上；领域知识是否得到沉淀，是否有人能承担“领域专家”；

高德商业框架（Gaode Business Framework），它是一种集成了业务身份与情境策略的综合性框架，由高德信息业务精心打造。其设计初衷是为了实现业务身份和场景策略的无缝对接。GBF深受TMF（技术管理框架）的启发，并融合了领域驱动设计（Domain-Driven Design, DDD）的先进思想，致力于为产品业务和技术开发提供一个既全面又高效，同时具备跨行业、多场景适应力的轻量级解决方案。GBF作为一种创新的业务框架，它不仅仅是一个技术工具，更是一种全新的商业思维。

领域驱动设计（Domain-driven Design，DDD）是一种软件设计方法，该方法的核心思想是将业务领域作为设计和开发的中心，强调对业务领域的深入理解、业务语言的建模以及领域对象的设计和实现。这样可以更好地将软件设计和业务需求紧密结合起来，从而提高软件的可维护性、可扩展性和可重用性，使得软件更加贴近业务需求。第1步：战略设计战略设计主要从业务视角出发，包括了业务场景分析、领域建模、划分边界上下文三个阶段。限界上下文可以作为微服务设计的参考边界。第2步：战术设计。

这里举一个简单的常见案例：下单链路。假设我们在做一个checkout接口，需要做各种校验、查询商品信息、调用库存服务扣库存、然后生成订单：@Resource@Resource@Resource// 1) Session管理// 2）参数校验// 3）外部数据补全// 4）调用外部服务if (!// 5）领域计算// 6）领域对象操作// 7）数据持久化// 8）返回为什么这种典型的流水账代码在实际应用中会有问题呢？

Model（模型）：承载着业务的属性和具体的行为，是业务表达的方式，是DDD的内核。Model（模型）是一个类中有属性、属性有Get/Set方法，并且业务的行为（Action）操作也是在模型类中（充血模型）模型分为Entity、Value Object、Service这三种类型ECS架构模式是其实是一个很老的游戏架构设计，最早应该能追溯到《地牢围攻》的组件化设计，但最近因为Unity的加入而开始变得流行（比如《守望先锋》就是用的ECS）。