在现实中我们会遇到各种各样的复杂场景，"There is not a right way" 用来描述API的设计方法再合适不过了，没有一种API设计方式可以应对所有的场景。区别于"Consumer-Driven Contract"，本文将描述另外一种设计API的方式：Domain-Driven API。这不是API设计的标准方法，但是他也许可以给你灵感，帮助你设计出更加具有表达力的API。
POST /api/customer
POST /api/customer/order
PUT /api/customer
POST /api/customer/notification
上图是一个API文档片段，他们通过HTTP动作加上统一资源标识符(URI)来描述自己的意图，也许还需要一份不错的文档来描述他的参数，返回类型等，就能被客户端调用和使用。市面上也有类似Swager这样高效的产品，用起来也很方便。但是这样的API或多或少有一些设计方面的小问题：
无法通过API描述上下文
纵然一个HTTP动词加上一个描述API资源的名词基本可以能够描述其意图，但是在使用过程中一份API文档似乎还是少不了。在过去的若干年里我去掉了给代码写注释的坏毛病，因为我认识到良好的组织结构和代码是自描述的。然而当我们设计API的时候，大家不约而同的接受了编写文档的事实。在"Consumer-Driven Contract"过程中还要编写一份契约测试来驱动服务端保证契约的一致性。有没有可能让API资源包含这一份契约，同时让消费者去遵守契约呢？
API消费端知道的太多
在上图的API文档片段中，你知道应该在什么时候调用下面的API吗？
POST /api/customer/notification
你可能不知道，也许是当用户下了订单，也或者是用户支付了订单，这取决于需求。似乎看起来合情合理，但是这样的场景预示着一部分领域逻辑有转移到消费端的嫌疑。打个比方，你去饭店吃饭，服务员拿过来了一个菜单，当你点了一分汤的时候服务员告诉你这个菜单有自己的规则，只有你先点一份蛋炒饭，你才能够点这份汤。这时候你只有一种选择那就是记住这个规则，下次先点蛋炒饭。有没有可能不要把这个规则强加在消费端呢？
易碎的设计
API以提供URI的方式来提供服务，而URI在本质上就是一个字符串，作为一个强类型玩家，我不希望这样的字符串分散在各个角落，试想我重命名了一个URI，我不得不搜索并修改所有曾经使用过这个资源的代码。
一、设计Domain我们在实践领域驱动设计时我们在做什么？找出领域边界、找到聚合根、划分Domain、根据Domain的能力做出抽象并设计良好的模型。而Domain在提供业务需求的过程就是Domain模型状态发生变化的过程。
同样的道理，我们设计API是为了达到什么目的？我希望我的API不但能够完成增删改查，还能够更具表达力。每一个API不是独立存在的，他们是Domain模型在某一时刻状态和能力的体现，每一个API资源在告知消费者目前Domain状态的同时，还可以告诉消费者当前Domain具备了什么样的能力，消费者接下来能够做什么，也即消费者能够请求哪一个API资源。
这么说来API的设计实际上跟Domain能力的设计有千丝万缕的关系,我决定用航空公司的卖票业务来举例说明。
业务需求：
一个叫做RestAirline的航空公司提供在线机票出售业务，用户可以按照搜索条件搜索到所有可用的航班(trip)
当乘客选中一条可用的航班(trip)就开始了整个预定(booking)流程
一旦乘客选择了一条可用的航班就可以修改航班(change trip)和选择座位(seat)
当乘客选择完座位还可以添加一些额外的服务，如：接送机服务(transfer service)等, 最后完成支付(payment)
乘客在飞机起飞前还可以做在线登机手续(checkin)并打印登机牌(boardingpass)，在Checkin的过程中还可以重新选择座位
注意： 括号中的英文术语可以理解为该公司的Domain language, 我们在领域建模的时候也会使用相同的术语，从而减少跟领域专家的沟通成本。
就上面的需求我们可以很容易的分析出若干个Domain: Booking, Payment, Trip Avalability
设计Booking Domain
我们以Booking Domain为例来描述设计过程，下面的交互图清晰的描述出了Booking的能力
实现Booking Domain
实现过程也相当的直接，如果将下面的代码阅读出来，几乎跟之前描述的业务需求是完全匹配的。Booking Domain的实现需要注意下面几点：
所有属性都是private set，意味着Domain的内部属性是靠自己维护的；