显然前一种地址包含的信息更多，它告诉了访问者订单（orders）是属于用户（users）这个实体中的一个子实体，并且包含了一个潜在业务规则，即如果ID为123的这个用户不存在了，那么查询他下面的所有订单信息也是不具有业务意义的。实体之间的嵌套关系可以通过领域建模过程中的聚合识别。当然，这种URL结构有时会导致很长的API路径，但相比它所带来的业务语义，我们认为还是值得的。

类似的语义化例子还有例如：

• PUT /services/questions/123

• PUT /services/questions/123/comments/123

这是售后服务部分的两个API，分别用来更新提问的内容和提问的评论内容，它们也是按层级组织的。

有些通信协议中还提供了其他可以表明业务语义的元素。比如RESTful中使用GET/POST/PUT操作语义（查询/创建/修改），以及HTTP返回值中的语义信息等。在实际设计API时充分利用这些协议特性，能够使服务变得更加易用。

尾声

在这篇文章里，我们列举了一些微服务划分的实践中常见的反例和值得注意的问题，希望能为读者设计微服务架构时扫清一些阻碍。实际上，本文中提到的许多概念，包括微服务和领域驱动设计，服务的划分都只是其中的冰山一角，在冰水之下还有更多的内容值得我们在实践中去探索。

作者：林帆，ThoughtWorks咨询师

本文为《程序员》原创文章，未经允许不得转载，更多精彩文章请点击「阅读原文」订阅《程序员》。

SDCC 2017·深圳站之架构&大数据技术实战峰会将于2017年6月10-11日于深圳南山区中南海滨大酒店举行，集阿里、腾讯、百度、滴滴出行、Intel、微博、唯品会的资深架构师和一线实践者，纳知名研发案例，遇见苏宁云商大数据中心总监陈敏敏、Apache RocketMQ联合创始人冯嘉、饿了么大数据平台部总监毕洪宇等大牛。