随着微服务得到更广泛的实践，我们听到了更多不同的声音，有赞誉的也有疑惑批判的。但这种松散耦合的面向服务的架构的创新，本身从设计理念来说，是强大的。而作为设计微服务时必不可少的工具——领域驱动设计 (DDD)，它更是思想精髓所在。今天就来聊聊关于DDD与微服务的那些事。
DDD是什么？
领域驱动设计因 Eric Evans 的著作而出名，它是一组思想、原则和模式，可以帮助我们基于业务领域的底层模型设计软件系统。开发人员和领域专家一起使用统一的通用语言创建业务模型。然后将这些模型绑定到有意义的系统上，在这些系统和处理这些服务的团队之间建立协作协议。更重要的是，它们设计了系统之间的概念轮廓或边界。
微服务设计从这些概念中汲取了灵感，因为所有这些原理都有助于构建可以独立变更和发展的模块化系统。
基本术语
领域（Domain）： 代表组织所做的工作。例如零售或电子商务。
子域（Subdomain）： 组织或组织内的业务部门。一个领域由多个子域组成。
统一语言（Ubiquitous language）：这是用于表达模型的语言。在下面的图示中，Item 是一个模型，它是每个子域的统一语言。涉及业务的众方都能就使用这种语言达成一致。
界限上下文（Bounded Contexts）：领域驱动设计将界限上下文定义为“一个单词或语句出现时确定其含义的设置”。例如，在上图中，“Item”在每个上下文中都有不同的含义。在 Catalog 上下文中，Item 表示可出售的产品，而在 Cart 上下文中，它表示客户已添加到购物车中的商品选项。在 Fulfillment 上下文中，它表示将要运送给客户的仓库物料。这些模型各不相同，每个模型都有不同的含义，并且可能包含不同的属性。
微服务和界限上下文如何关联
每个界限上下文都能映射到对应的微服务吗？这可不一定。举个栗子：
定价界限上下文有三个不同的模型：价格（Price）、定价项（Priced items) 和折扣（Discounts），分别负责目录项的价格、计算列表项的总价以及各自使用的折扣。可以创建一个包含上述所有模型的单一系统。但随着时间的推移，这个系统就可能会变成一个大泥球，界限模糊，职责重叠，甚至很可能会回到我们开始的地方——单体应用。对这个系统建模的另一种方法是将相关模型分离或分组到单独的微服务中。
在 DDD 中，这些模型（价格、定价项和折扣）被称为聚合（Aggregates）。聚合是由相关模型组成的自包含模型。我们只能通过已发布的接口来变更聚合的状态，并且聚合可以确保一致性，而且不变量可以始终保持良好状态。在形式上，聚合是关联对象的集群，被视为数据变更的单元。外部引用仅限于指定聚合的一个成员，即聚合根。在聚合的边界内需应用一组一致性规则。
需要注意的一点是，一致性只在单个聚合中才能得到保证，并且聚合只能通过已发布的接口进行修改。任何违反这些规则的行为都有增加应用程序变成一个大泥球的风险。所以一般团队会这样分工，DDD主要让产品组来做，因为他们有能力、有兴趣跟领域专家对话，划分出正确的Bounded Context；一旦形成领域设计，交付组就可以愉快地实现成微服务。
文章部分素材来源：InfoQ
