模拟业务场景，咖啡馆会员卡
由于所在项目的安全性需求，我们不可以向外暴露客户的相关信息，由此产生的各种痛点我就不吐槽了，完全一把辛酸泪，公司发了rMBP都只能在客户的远程Windows机器上慢腾腾地工作。所以在这一篇文章里，就先来模拟一个类似的业务场景，之后的讨论都将基于此业务场景进行展开。当然，详细的需求不会一开始就全部阐述清楚，过早描述细节也是徒劳，只有在具体的技术应用时才会谈及相关的业务价值，而在此之前，还是让我们来看看什么的场景才是比较可靠的。
首先，咖啡馆这个Idea是来自于最近所看的一本书（REST实战），由三位工程师共同编著，两位来自ThoughtWorks，另一位来自MicroSoft，除了有些翻译问题外整体感受还不错，在这里推荐一下。书中谈及的需求就是借鉴了把咖啡馆开满全世界的星巴克，模拟了一个RestBucks的业务场景，描述了客户购买咖啡，查看订单状态，以及取咖啡等操作，然后咖啡馆就需要处理用户的买单，加糖等需求变更，以及制作咖啡等等，这样就很生动形象地描述了REST中的CRUD操作和相对应的HTTP方法。
而目前来说，我们的真实项目需求也比较类似，说实话其实并没有达到这样的复杂度，但是借鉴于咖啡馆这个想法还是足以说明问题了。而且购物买东西这种场景在生活中非常常见，也便于理解，并且易于扩展想法，想象力就在此展开吧。
开满全球的Restbucks
Restbucks是闻名海外的一家历史悠久的咖啡馆，主营速溶咖啡以及手工研磨等多种咖啡品种，在历经风雨的途中也是收购了众多其他品牌的咖啡馆。现在为了应对互联网潮流，更好地满足用户的多方位需求，推出了统一的电子会员卡以及快递送货服务，让用户在家中也可以轻松享用到Restbucks所提供的优质咖啡。由此，Restbucks找到了在软件开发行业享有盛名的ThoughtWorks，为其开发对应电子渠道的在线办卡、咖啡销售、快递上门等在线服务。
业务需求上来还是比较简单的，但是由于Restbucks旗下已经收购了很多不同的品牌，而在这之前各个品牌或多或少都已经实现了一部分功能，也分别拥有属于自己的用户数据库以及所对应的咖啡销售数据。而其中最大的挑战就是如何将来自于不同数据库的数据进行整合，并且设计和实现统一的接口供外部使用，这就是Restbucks的「品牌集成战略」。
目前已知的品牌包括Venus、Jupiter、Mercury、Mars、Saturn等等，这些平台的用户群定位各有不同，当然它们所提供的各项服务也会有些许的差异，这些差异所导致的各种问题以及如何从技术上进行规避，都会在之后的具体实现中进一步讨论。
在线办卡
用户在登录
送货上门
目前所专注的点在于Restbucks并没有自家的送货平台，所以选择与一家名为247的快递公司进行合作。向247快递公司提供接口，提供其所需的相关用户信息以便于送货。在用户下单之后就会得到一个「订单号码/order number」，快递员可以使用这个号码在就近的Restbucks旗下的咖啡馆领取咖啡，再送至用户所在地。而在完成送货之后，快递员也可以通过设备直接向Restbucks表示已完成该订单「lodge order」，此时除了需要提供之前会员所使用的「loyalty number」以外，还需要将当前所在位置和日期已验证是否符合正式交易要求。
系统架构及其依赖
接口设计及其依赖：
- 用户信息 b2b-customer-service
- customer-api 提供RESTful API的用户信息接口
- product-api 提供用户在Restbucks所充值的会员卡号码
- self-loyalty-service 提供用户的所有会员卡具体信息
- 会员卡信息 b2b-loyalty-service
- global-customer-identifier-center 提供用户的个人身份信息
- self-loyalty-service 提供不同品牌会员卡的统一接口
- wmb 提供每个会员卡的具体信息，部分品牌
- group protect 提供每个会员卡的具体信息，但支持的品牌不同
- order centre 提供不同种类咖啡的可购买次数
- 咖啡订单信息 b2b-order-service
- order centre 提供咖啡交易的具体信息