渐进式消费

最近在学习徐昊老师的《如何落地业务建模》，第11讲 “将模型实现为RESTful API（下）”，提到一个非常有意思的概念渐进式消费。

我对这章印象非常深。因为我们的业务是经常会有多个页面内容类似但不完全相同的情况。这个时候我看到项目里就充斥着大量重复的代码，几乎是每个页面都是重新写一套controller - service - mapper。时间一长，这样的代码就成了非常累赘的历史包袱，维护起来非常困难。

徐昊老师的这篇文章告诉我们可以通过渐进式消费来解决这个问题。渐进式消费其实非常常见。在前面应该到处都是这样的代码。一个页面需要非常多的数据，不是通过平铺直叙地直接从后端获取，而是可以通过“服务增强”的方式渐进式地获取。类似徐昊老师文章中举出的一个例子

Content-Type: application/hal+xml
<resource rel="self" href="/orders/523">
    <link rel="warehouse" href="/warehouse/56"/>
    <link rel="invoice" href="/invoices/873"/>
    <currency>USD</currency>
    <status>shipped</status>
    <total>10.20</total>
</resource>


Content-Type: application/hal+json
{
  "_links": {
    "self": { "href": "/orders/523" },
    "warehouse": { "href": "/warehouse/56" },
    "invoice": { "href": "/invoices/873" }
  },
  "currency": "USD",
  "status": "shipped",
  "total": 10.20
}

其实我们做整个服务的时候也可以借鉴这样的方式。先提供一个较为通用的接口，然后通过“增强”的方式满足不同的功能需求。这样就可以在服务端维持一个较为稳定的状态。当然这样来做肯定会遇到性能问题，徐昊老师的观点是通过缓存来解决。

实际应用中，我们不一定要按照老师提供的做法，更重要的是理解这个思想。比如在我们项目中，要推行老师的这套做法可能会有一些阻碍和成本。因为这个需要整个项目组配合。但是这个思想可以指导我们将服务写成分层结构，底层稳定，上层通过组合底层接口来满足不同的需求。