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

网上有非常多关于DDD的文章，这当然是好事情，大家都想掌握好的设计方法来解决软件开发中的问题。但是这其中也存在一些问题，如果你随便打开网上的几篇DDD文章，虽然每一位作者都说自己是按照DDD思路进行架构设计的，但是细心的同学会发现每一个作者DDD文章中的结构描述、画的架构图都千差万别，你会非常奇怪，这些都是DDD设计吗？这里其实有一个问题，就是通过文字和图示描述一些抽象的概念时，本来就会有很大的差别。大家不要用盲人摸象的概念进行类比，这个不太合适，即便两个同学，对DDD都非常了解，而且都实践了好几年多个项目，他们写出来的东西还是不一样。我Java入行稍微早点，当然你说我年纪大保守也可以，记得当初没有那么多中间件，就是基于Struts 1.x这个MVC框架进行开发，不同的同学写出的设计文档也是千差万别。这么简单的MVC架构都能有不同的架构设计文档，而DDD相对更抽象、更难以理解，所以架构设计文档长的不太一样，这个也是可以理解的。

那么我们是不是要接受这个事实，“各个作者对DDD的解释可以不必相同”，"DDD设计文档可以以不同种形式呈现"？如果是这样，那么想学习DDD的同学就有非常大的负担，哪种设计表现方式才是比较好的，才是比较容易理解的，同时我怎么知道我学的DDD是相对正统的，没有被别人带歪。我不是说发挥性思考不可以，但是从传道的角度来说，尊重理论事实还是需要的。

我们都知道代码在表达一些业务或者逻辑时，非常能反应真实情况，即便是不同的开发者所编写，考虑到遵循Design Pattern、命名规范、开发语言约束等，代码大体上还是相同的，还是便于理解的，如果有单元测试和Code Review，那就更好啦。这也是在一些文档不完善的时候，非常多同学选择阅读代码，更有同学说，“直接看代码，不要看他们PPT和文档，会被误导的，不然怎么死的都不知道”。另外我们都知道，现在一个非常好的实践就是Everything as Code，典型的如Infrastructure as Code的Terraform，Platform as code的Kubernetes YAML, Diagram as Code的PlantUML等等， 那么我们能否使用DDD as Code这个概念，让我们的设计更统一些，更能方便表达设计思想，更容易被人理解。

DDD DSL

用DSL也就是用代码方式来表达DDD，这个很早就有了，但是更偏向DDD的战术设计(Tactic Design)和代码层面，如 Sculptor[1]和fuin.org DDD DSL[2] ，大家普遍都认为，就是基于Xtext的DDD代码生成器。要费劲学习那么多，只为生成一些代码，而且只是Java代码，所以普遍关注度并没有多高。

我们能否将DDD DSL除了代码生成这一部分，更偏向于战略设计(Strategic Design)，突出设计的思想，那么DDD as Code就全面多了。接下来我们就介绍ContextMapper这个框架。

名词解释一下：有不少同学对于DDD的战略设计(Strategic Design) 和战术(Tactic Design)之间区分有些疑惑，DDD有专门的介绍，如下：

• 战术设计(Tactic DDD)：Entity, Value Object; Aggregate, Root Entity, Service, Domain Event; Factory, Repository。
• 战略设计(Strategic DDD)：Bounded Context, Context Map; Published Language, Shared Kernel, Open Host Service, Customer-Supplier, Conformist, Anti Corruption Layer (context relationship types)。

其实也比较简单，战略设计更大一些，偏宏观，你可以理解为公司高层在讨论的业务和技术方向，各个团队或者产品的分工和配合；而战术设计则相对小很多，主要集中在一个BoundedContext内部，比如如何设计DDD那些Entity，Service，Repository等，外加可能的应用开发的技术选型，可以说更关注技术层面。

ContextMapper框架介绍

ContextMapper是一个开源项目[3] ，主要是为DDD设计提供DSL支持，如DDD的战略(Strategic)设计，Context间映射(Context Mapping)，BoundedContext建模以及服务解耦(Service Decomposition)，那么我们就看一下如何基于ContextMapper来完成一个项目基于DDD DSL的表达。

在介绍ContextMapper时，我们先交代一下项目背景。如花是一名架构师，对DDD也非常熟悉，而且有过几个项目的DDD实践，最近他加入会员线，负责完成对会员系统的改造，更好地配合公司的微服务化的设计思路。会员线之前就是三个应用：会员中心对外提供的大量的REST API服务；会员注册和登录应用；会员中心，处理会员登录后如修改个人密码、基本信息、SNS第三方绑定和支付方式绑定等。

如花加入会员团队后，和大家沟通了基于DDD + MicroServices的架构思想，大家都表示同意，但是如何落实到具体的架构设计和文档上，大家就犯难啦。让我们看一下最典型的DDD设计图：

其中的概念，如SubDomain、BoundedContext、Entity、ValueObject、Service、 Repository、Domain Event，以及Context映射关系(Context Mapping)，这些都没有问题，但是如何向他人表达这个思想？总不能每次都把DDD设计图和分层图都贴上去，然后说我就是按照DDD设计的。

从SubDomain开始

如花开始DDD的第一步，也就是Subdomain的划分。当然DDD中包括三种类型的SubDomain，分别为通用(Generic)、支撑(Supporting)和核心(Core)三种类型，这里稍微说明一下这几者的区别：

• 通用(Generic) Domain: 通用Domain通常被认为已经被行业解决的问题，如架构设计中的可观测性的Logging、Metrics和Tracing，各种云服务(Cloud Service)等，这些都已经有比较好的实现方案，对接就可以。当然业务上也有，如成熟的行业解决方案，如ERP、CRM、成熟硬件系统等，你购买就可以啦。
• 支撑(Supporting) Domain：和通用Domain类似，但是系统更来自内部或者还需要在通用的基础上进行一些定制开发。如一个电商系统，会员、商品、订单、物流等业务系统，当然还有一些内部开发的技术类型支撑系统。
• 核心(Core) Domain: 也就是我们常说的业务核心，当然如果是技术产品，就是技术核心，这个也就是你最要关注的。

这三者整体关系如下：Core是最与众不同且花费精力比较多的，在复杂性Y维度，我们要避免高复杂度的通用和支撑Domain，这样会分散你的注意力，同时还要投入非常大的精力，如果确实需要，购买服务的方式可能最佳。

图源：
https://github.com/ddd-crew/ddd-starter-modelling-process

如花首先将会员先划分为几个Sub Domain，如处理账号相关的Account，处理会员打标的UserTag，处理支付方式的PaymentProfile，处理社交平台集成的SnsProfile，还有一个其他Profiles，这里我们不涉及Generic和Supporting Doman的规划，主要从业务核心Domain出发。一个同学用PPT阐述了划分结构和出发点，如下：

但是也有同学说是不是UML的Component图更好一些，方便和后面的UML图统一，如下：

当然还有其他如Visio等非常多的图示工具用于展现结构图。DDD的第一步：SubDomain的划分和展现，就有不同的理解方式，如何描述、如何图形化展现，都有不少的分歧。

回到问题的出发点，我们就想划分一下SubDomain，那么是不是下述的DSL代码也可以：

Domain User {
    domainVisionStatement = "User domain to manage account, tags, profiles and payment profile."
    Subdomain AccountDomain {
       type = CORE_DOMAIN
       domainVisionStatement = "Account domain to save sensitive data and authentication"
    }
    Subdomain UserTagDomain {
       type = GENERIC_SUBDOMAIN
       domainVisionStatement = "UserTag domain manage user's KV and Boolean tag"
    }
    Subdomain PaymentProfileDomain {
        type = CORE_DOMAIN
        domainVisionStatement = "User payment profile domain to manage credit/debit card, Alipay payment information"
    }
    Subdomain SnsProfileDomain {
        type = CORE_DOMAIN
        domainVisionStatement = "User Sns profile domain to manage user Sns profile for Weibo, Wechat, Facebook and Twitter."
    }
    Subdomain ProfilesDomain {
        type = CORE_DOMAIN
        domainVisionStatement = "User profiles domain to manage user basic profile, interest profile etc"
    }
}

虽然目前我们还不知道对应的DSL代码语法，但是我们已经知道Domain的名称、domain类型以及domain的愿景陈述(visionStatement)，至于后期以何种方式展现系统Domain，如表格、图形等，这个可以考虑基于现在的数据进行展现。其中的UserTagDomain类型为GENERIC_SUBDOMAIN，这个表示打标是通用性Domain，如我们后期可以和商品、图片或者视频团队合作，大家可以一起共建打标系统。

注意：Subdomain不只是简单包括type和domainVisionStatement，同时你可以添加Entity和Service，其目的主要是突出核心特性并方便你对Domain的理解，如Account中添加resetPassword和authBySmsCode，相信大多数人都知道这是什么含义。但是注意不要将其他对象添加到Subdomain，如VO, Repository, Domain Event等，这些都是辅助开发的，应该用在BoundedContext中。

Subdomain AccountDomain {
       type = CORE_DOMAIN
       domainVisionStatement = "Account domain to save sensitive data and authentication"
       Entity Account {
         long id
         String nick
         String mobile
         String ^email
         String name
         String salt
         String passwd
         int status
         Date createdAt
         Date updatedAt
       }
      Service AccountService {
          void updatePassword(long accountId, String oldPassword, String newPassword);
          void resetPassword(long acountId);
          boolean authByEmail(String email, String password);
          boolean authBySmsCode(String mobile, String code);
      }
    }

Context Map

ContextMap主要是描述各个Domain中各个BoundedContext间的关联关系，你可以理解为BoundedContext的拓扑地图。这里我们先不详细介绍BoundedContext，你现在只需要理解为实现Domain的载体，如你编写的HSF服务应用、一个处理客户请求的Web应用或者手机App，也可以是你租用的一个外部SaaS系统等。举一个例子，你的系统中有一个blog的SubDomain，你可以自行开发，也可以架设一个WordPress，或者用Medium实现Blog。回到微服务的场景，如何划分微服务应用？SubDomain对应的是业务或者虚拟的领域，而BoundedContext则是具体支持SubDomain的微服务应用，当然一个SubDomain可能对应多个微服务应用。

既然是描述各个BoundedContext关系，必然会涉及到关联关系，如DDD推荐的Partnership([P]<->[P])、Shared Kernel([SK]<->[SK])、Customer/Supplier([C]<-[S])、Conformist(D,CF]<-[U,OHS,PL])、Open Host Service、Anticorruption Layer([D,ACL]<-[U,OHS,PL])、Published Language等，详细的介绍大家可以参考DDD图书。这些对应关系都有对应的缩写，就是括号内的表述方法。这里给出关联关系Cheat Sheet说明图：

图源：
https://github.com/ddd-crew/context-mapping

如果你自行画图来表达这些关系，一定有非常多的工作量，细致到箭头类型，备注等，不然会引发误解。这里我们就直接上ContextMapper DSL对ContextMap的描述方式，代码如下：

ContextMap UserContextMap {
   type = SYSTEM_LANDSCAPE
   state = TO_BE
   contains AccountContext
   contains UserTagContext
   contains PaymentProfileContext
   contains SnsProfileContext
   contains ProfilesContext
   contains UserLoginContext
   contains UserRegistrationContext
    UserLoginContext [D]<-[U] AccountContext {
        implementationTechnology = "RSocket"
        exposedAggregates = AccountFacadeAggregate
    }
    ProfilesContext [D]<-[U] UserTagContext {
        implementationTechnology = "RSocket"
        exposedAggregates = UserTags
    }
    UserRegistrationContext [D,C]<-[U,S] UserTagContext {
        implementationTechnology = "RSocket"
        exposedAggregates = UserTags
    }
    UserRegistrationContext [D,C]<-[U,S] SnsProfileContext {
        implementationTechnology = "RSocket"
    }
}

大家可以看到Map图中包含的各个BoundedContext名称，然后描述了它们之间的关系。在关联关系描述中，涉及到对应的描述。前面我们说明BoundedContext为Domain的具体系统和应用的承载，所以涉及到对应的技术实现。如HTTP REST API、RPC、Pub/Sub等，如blog系统为Medium的话，那么implementationTechnology = ”REST API"。还有exposedAggregates，表示暴露的聚合信息，如class对象和字段，服务接口等，方便通讯双方做对接，这个我们会在BoundedContext中进行介绍。

BoundedContext

在ContextMap中我们描述了它们之间的关联关系，接下来我们要进行BoundedContext的详细定义。BoundedContext包含的内容相信大多数同学都知道，如Entity， ValueObject，Aggregate，Service，Repository、DomainEvent等，这个大家应该都比较熟悉。这里我们给出一个ContextMapper对BoundedContext的代码，如下：

BoundedContext AccountContext implements AccountDomain {
    type = APPLICATION
    domainVisionStatement = "Managing account basic data"
    implementationTechnology = "Kotlin, Spring Boot, MySQL, Memcached"
        responsibilities = "Account", "Authentication"
    Aggregate AccountFacadeAggregate {
       ValueObject AccountDTO {
          long id
          String nick
          String name
          int status
          Date createdAt
          def toJson();
       }
       /* AccountFacade as Application Service */
       Service AccountFacade {
          @AccountDTO findById(Integer id);
       }
    }
    Aggregate Accounts {
         Entity Account {
            long id
            String nick
            String mobile
            String ^email
            String name
            String salt
            String passwd
            int status
            Date createdAt
            Date updatedAt
         }
   }
}

这里对BoundedContext再说明一下：

• BoundedContext的名称，这个不用说啦，这个和ContextMap中名称一致。
• implements AccountDomain：表示要实现哪一个SubDomain，我们都知道一个Subdomain可能会包含多个BoundedContext，这些BoundedContext配合起来完成Subdomain的业务需求。ContextMap还提供refines，来表示BoundedContext要实现一些user case，官方文档有对应的说明。
• BoundedContext的属性字段：type表示类型，如APPLICATION、SYSTEM等。domainVisionStatement描述一下BoundedContext的职责。implementationTechnology表示具体的技术，前面我们说到BoundedContext已经涉及具体的应用和系统等，所以要说明对应的技术方案实现，核心的部分描述一下就可以。responsibilities 表示BoundedContext的职责列表，这里只需要关键字就可以，如Account要负责安全验证等。

• AccountFacadeAggregate: 表示提供给外部调用的聚合，这里DTO的对象定义、服务接口的定义等。
• Aggregate Accounts：这个表示BoundedContext内部的聚合，如entity、value object、service等。这里说明一下，DDD中的那个Aggregate是entity，value object的聚合对象，而ContextMapper中的Aggregate表示为一些资源的集合，如Service集合等。

BoundedContext的更多信息，可以参考sculptor的文档[4]，根据实际的情况可以添加对应的部分，如DomainEvent、Repository等。

个人觉得这里BoundedContext还没有涉及到Ubiquitous Language，还是需要对应的辅助设计文档，需要交代相关的项目背景，技术决策等等。个人是推荐采用C4架构设计作者编写的 《Visualise, document and explore your software architecture》[5]，非常实用，作为DDD架构设计文档，完全没有问题。

文章的一开头我们说到之前的DDD DSL更多的是代码生成器，如果是代码生成器，那么生成的代码一定有对应的规范和结构等，如entity、value object，service，repository保存的目录，生成的代码可能还包括一定的Annotation或者interface，标准字段等等。当然这里我们不讨论代码生成器的问题，但我们希望大家的DDD架构设计还是要采用一定的规范目录结构，这里有几个标准推荐给大家：

• ddd-4-java: Base classes for DDD with Java[6]

• jDDD：Libraries to help developers express DDD building blocks in Java code[7]
• ddd-base: DDD base package for java[8]

这三者其实出发点都是一致的，就是在代码层面来描述DDD，核心是一些annotation、interface，base class，当然也包括推荐的package结构。

ContextMapper的其他特性

讲到这里，其实DDD整体上来说，我们已经阐述清楚：Domain划分、整体Domain的BoundedContext拓扑图和关联关系、BoundedContext具体定义和架构设计文档规范。但是ContextMapper还提供了UserStory和UseCase对应的DSL，让我们来看一下。

UserStory

好多同学都问UserStory如何写，有了这个DSL，同学们再也不用担心如何编写UserStory啦。这个DSL比较明确的，主要是三元素：作为 “aaa"，我希望能"xxx"，我希望能”yyyy"，以便 "zzz"， 也是符合UserStory的典型三要素：角色、活动和商业价值。

UserStory Customers {
    As a "Login User"
        I want to update a "Avatar"
        I want to update an "Address"
    so that "I can manage the personal data."
}

UseCase

Use Case是描述需求的一种方式，在UML图就有对应的UseCase图，核心就是actor，交互动作和商业价值，对应的DSL代码如下：

UseCase UC1_Example {
  actor = "Insurance Employee"
  interactions = create a "Customer", update a "Customer", "offer" a "Contract"
  benefit = "I am able to manage the customers data and offer them insurance contracts."
}

在Aggregate聚合中，你可以设置useCases属性来描述对应的UseCase， 如下：

Aggregate Contract {
  useCases = UC1_Example, UC2_Example
}

ContextMapper带来的收益

按照你的说法，我们用DSL代码方式来描述DDD，这个有什么收益？

架构设计标准化

这种代码方式，一目了然且非常规范。如果你代码写错会有什么问题，当然是编译不通过，IDE都会帮你纠正。所以DDD DSL也是这样，完全无歧义。目前ContextMapper DSL包括Eclipse和VS Code插件，在IntelliJ IDEA可以通过自定义File Types和Live template方式来辅助你编写cml文件。

生成器(Generators)支持

前面我们聊到DDD DSL支持代码生成器，可以辅助你生成代码，相信这个大家都能明白，因为DDD DSL代码是标准的，基于这个Code Model生成其他形式的代码，这个当然可以。

另外ContextMapper还支持其他模型生成，如ContextMap图形化展现、PlantUML的结构图，对应的代码在这里[9]。我这里给大家一些截图：

当然ContextMapper还提供通用的生成器，也就是基于DDD DSL模型，加上Freemarker模板，然后就可以生成你想要的各种输出，如生成JHipster Domain Language (JDL)用于快速创建文件脚手架也不奇怪。相信很多Java程序员对此都不陌生，我们开发Web应用时就是使用Freemarker生成HTML的。更多细节访问这里[10]。

现实中的DDD设计流程

我们有了DDD DSL来描述我们的架构设计，是不是就全面了，完全够用，开发不愁了呢。还不是，我们知道在软件架构设计和编写代码前，都有需求调研、客户走访、领域专家沟通、需求分析、研讨等等，这个在现实生活中还是少不掉的，其目的就是为了后续的架构设计提供素材并做铺垫。那么如何将DDD和这些前期操作整合起来？其实DDD有涉及这方面的内容，如EventStorming卡片：

Bounded Context Canvas卡片：

如果你在需求分析阶段注意这些DDD卡片的使用，那么后续的DDD设计就会有更好的素材，当然还有UserStory和Use Case等。

个人建议：如果你有时间的话，强烈建议关注一下ddd-crew[11] ，有非常全面的DDD相关的最新并实用的知识和实践。

DDD和MicroServices的关系

和DDD DSL无关，只是稍微提及一下。微服务架构设计在于如何将复杂的业务系统划分为密切合作的微服务应用，划分的依据就显得非常重要。SubDomain从业务的角度出发，进行业务边界的划分，而BoundedContext则是关注于业务领域对应的应用承载。而Generic类型BoundedContext可以同时支撑多个SubDomain，能够做到不同业务系统的应用复用。如果在Cloud Native的场景中，我们希望更多的使用System类型的BoundedContext，也就是重复利用云上的系统，从而减少自己的开发和维护成本。回到Appplication类型的BoundedContext，这个就是你要具体开发的应用，你选择哪些微服务框架，这个你可以自行决定。整个过程，DDD都起到应用划分的理论基础作用。

但这里还有一个问题，就是微服务之间的通讯问题，你可以反复强调我们需要构建强大的分布式应用，但是推荐的技术栈是什么？如何去做？而且还要做的更好，这个并没有明确说明，所以大家选择REST API、gRPC、RPC，Pub/Sub等等混合通讯技术栈。

关于BoundedContext之间的关联关系DDD已经给出了(partner ship, c/s, share kernel等)，但是具体到通讯和协作，并没有给出很好的理论基础， 但是这个在DDD社区也有一些共识，就是基于异步化的消息通讯 + 事件驱动是比较好的方案，所以你看到DDD的首席布道师Vaughn Vernon反复讲到DDD + Reactive，就是为了解决ContextMapping的通讯问题。

说到这里，如果你看到ContextMapper支持MDSL (Micro-)Service Contracts Generator的输出，那么也就不奇怪了，也是理所当然的事情。

更多的关于MicroServices和DDD关系，你可以参考《Microservices love Domain Driven Design, why and how?》[12]

总结

ContextMapper提出的DSL概念还是非常好的，至少让大家在DDD的理解上歧义少啦，同时也规范啦，DDD初学者的门槛也降低，虽不能到架构设计的地步，至少阅读理解起来无障碍。在我编写这篇文章的时候，ContextMapper DSL 5.15.0版本已经发布，相关的特性都已经全部开发完毕啦，使用起来还是非常顺畅的。当然落实到实际开发，DDD as Code这种方式是否有效，还希望做DDD实践的同学给出宝贵的意见。

当然我一篇文章并不能将ContextMapper阐述的非常清楚，contextmapper[13]上有非常详细的文档和对应的相关论文， 当然你可以不采用DSL这一套思路，但是这些思想和相关的资料对DDD设计还是帮助非常大的。

另外个人更觉得，如果你是DDD的初学者，那么ContextMapper可能更合适，DDD是方法论，那些图书都枯燥的要死，看两章节不犯困几乎非常难的。相反如果你学习DDD DSL那就简单多，这个DSL再复杂也不会比你学习的编程语言复杂吧？相反这个DSL是非常简单的，通过简单的DDD DSL学习，你会很快掌握其中的概念、思路和方法，不行就看一下其他人的代码（DDD DSL examples），也会帮助你很快学习，掌握这些方法论，回头你再使用图书和文章进行巩固一下，也是非常好的。

作者：茶什！

本文为阿里云原创内容，未经允许不得转载