SOA指的是Service-oriented Architecture，面向服务的架构。
很多年前有一家生产家电的公司，由于物美价廉产品十分畅销，但随着顾客的增加企业面临一个棘手的问题：维修服务。一开始维修服务是公司的一个小部门，在专卖店的一个角落里，随着很多顾客都需要维修，哪怕是普通的更换零件，专卖店变成了维修店，维修服务的供给不足开始给竞争对手和专业的碰瓷者带来了机会。
于是这个公司采取维修授权的方法，第一批取得授权的是一些信誉好的家电维修公司/作坊，一度一个维修部牌匾上有这家公司的名称是这个维修部实力的见证。
后来一个新问题产生了，许多维修部在没获取授权的情况下擅自代理维修业务，导致保修体系受到破坏，公司开始明察暗访跟很多维修部斗争。再后来公司想到了一个新办法：把维修授权及监管代理给专门的授权公司，让后者跟授权的维修店协调并负责调查、举报、起诉冒充授权的维修部，由此带来的好处由公司和授权公司分成。
而对于普通消费者，一开始左右的事情都要跟家电公司打交道，难打通的热线、拥挤的专卖店/维修部影响了消费体验。后来不同的业务找不同的代理部门即可，比如送货预约提供在专卖店购买时的全国统一号码即可，对方负责安排其余事情，维修时候联系总的维修部门由他们基于产品种类、顾客的时间以及各维修店的位置、能力来安排维修方式（上门/自提）和时间。
这两天的小项目进展让我意识到，软件的结构和行为哪怕很小的一个方面都受到业务逻辑（business logic）的影响，我这个小工具虽然简单，但具体设计也要直接对应业务逻辑。
而业务逻辑方面，把纷繁复杂的行为和模块简化的绝好方式便是接口（api）。家电公司授权（提供接口）维修店（接口调用者），消费者（产品最终使用者）联系维修店（封装后的接口）。
但随着接口的复杂化，软件服务的购买者/使用者也常遇到各种困难。家电公司不跟维修店直接打交道，而是通过代理公司（一级接口），接口层层嵌套。
有了接口还不够，因为与接口的通信面临很多问题：
1 消费者不放心把数据直接交给服务提供者，如隐私问题、商业机密问题。通过记录搜索内容，一些商业机密就面临暴露的风险。像多吉搜索引擎的出现便是隐私方面的需求。
2 服务提供者多样化，消费者常常面临选择困难，或者/和需要同时使用多个接口解决单个需要。像聚合搜索这样的平台是普通搜索服务方面的反映，更专业的搜索可能有咨询公司。
3 接口使用本身难度增加。很多非IT公司，他们有IT部门，但独立根据api制作出自己需要的产品常常不现实或成本过高，于是软件公司的专业服务变得越来越重要，这些专业服务包括培训使用产品、协助二次开发开始也变成需要由专门公司承接的了。
4 接口的双向化：一方面数据托管，另一方面数据作为服务（DaaS），一个/一类接口其实聚合了很多功能和需要。
5 每个接口使用费用都不菲。
由此我想到的是：应该梳理一下作为跟接口打交道的中间层产品/服务，这个对了解软件开发非常重要。
几个设想，不知道现在有哪些实现：
1 聚合代理，共享经济：假设ABCD四个公司都要用到XYZ这三个产品，各自分别订购成本高，于是四家公司一起订购共享使用。于是产生了个问题：这些公司面临互相寻找共享伙伴的成本。
此时，需要产品共享平台。
2 API代理：直接共享面临另一个问题，即专用要求，不让分着用，一个产品一个企业买了就只能自己用。
但如果只能自己用，ABCD可能谁都用不起，此时不妨允许做适度共享的产品代理——XYZ产品都交给M公司，而且是远高于单价的，M公司利用它的资源寻找像ABCD这样的客户，然后分享给它们用，随后返给XYZ公司的利润高于零售价。
这个问题有另一个选择就是原子化计量（“货币化”），像CDN的按流量计费，用多少交多少钱。但是——
3 通过聚合去敏感隐私：ABCD公司与XYZ的通信涉及各自机密，就算他们能信得过XYZ不把数据外传，万一XYZ自己的系统被黑客攻击数据泄漏怎么办？
这是我写此文时最感兴趣的一点：大数据时代有些数据大了之后反而敏感度下降，比如小红的搜索记录里包括“单身女孩约会”、“判断渣男”等内容容易成为感情诈骗的对象，小刚的搜索记录却是“好老婆的标准”之类的东西，二者如果聚合在一起，外人就判断不出这些数据背后代表的是单身女孩还是一个单身男孩。
此时有了一个N公司，它的产品是接受ABCD的接口使用请求，ABCD的请求经过它以混淆、随机及延迟的方式输送到接口，然后把接口返回结果回传给ABCD。N不记录某个请求来自谁，可以通过ABCD自身的密钥实现，N只作为中间管道，或者数据被记录但用一些方法让它们的提取和分析非常非常困难（但请求结果A'->A的过程很容易），一段时间后自动销毁。