前篇只是部分的IT技术，其实一个标准的规范的Web Service开发远远不止如此，如果要求微服务和Serverless的方式的RESTful API交付，则需要考虑更多的东西。同时将涉及SOA和DDD的设计思路。
那本篇着重分享一下老东家的NDC的思路。
NDC Adapter
老东家历时近1年，在经费紧张的情况下，完成了一套基于NDC的NDC Adapter的方案及实现平台体系。
但是其终究是“an Orchestration Layer for exposing airline backend data using standard NDC messages.”，所以其是一个参考和应用某公共Interface标准的另外一套“Message Engine”的实现，一个消息转换的工具。
它的价值在于IT，而非业务或Business的价值。
因为其内部不包含真正的PSS或航司电商的逻辑，虽然其也有Biz Domain Entity的概念和实现，但是其命名和定位，以及NDC的本质，只能使其成为航司PSS和电商的一层“壳”。
a) “壳”很美丽，但是还需要逐一以代码adapter的方式接入航司或Travel的各类资源，DL对接了，并不能直接搬迁代码到UA，因为每个航司的IT实现，接口，数据，业务都不一样。
b) "壳"有价值，因为它确实能够提升IT的开发和交付能力，并且通用化和配置化很多代码实现，让航司或Travel实体投入较少的开发资源，就能够实现直销和数据/业务/产品/服务的暴露。
c) "壳"只能是“壳”，因为没有业务，不愿也无能为力去涉及航司电商真正的痛点，尤其是直销和新一代电商的数字化转型。
d) "壳"的面积有限，方便一个航司实现数据/业务/产品/服务的暴露，但是其必须有对接的需求，反而不能平台化。倘若有某一个独立于航司的NDC平台化厂商，能够将航司或Travel的资源整合成开放的标准的资源，那才是真正有意义的事情。其实Travelport对于NDC的支持，其实挺皆大欢喜的。但是仔细想想，支不支持NDC对于GDS有多大的重用性吗？他们已经都聚合了各类资源了，也按照自己的方式将数据/业务/产品/服务暴露了不少了。
其实也不能怪或说老东家的NDC Adapter不好，因为老东家有老东家的苦，有其思索问题和设计产品的思路。就好比之前的AIP一样，其价值不言而喻。但是必须拥有能够让这些平台或工具发挥热量的场景或土壤。
回想其之前的Message Engine，不考虑性能等NFR因素，其带来的航司数字化能力不言而喻，但是也许只能在国外适用，或者航信这样的客户。但是对于航司，IT觉悟再高，也不会使用或真正发挥价值。那些IT外包公司和人员干啥，划分千八百就让外包人员编码完成的一个小小功能，让航司业务人员自己折腾半天在界面上拖拉拽实现，他不管乐不乐意，至少没人敢说他这样拖拉拽完成的东西就能上生产环境。而且一年有多少次这样的需求变化呢？？？
所以行业的IT工具必须在特定的场景和环境下评判其价值，更应该看是哪些真正的客户，最终用户。
航司直销平台或LCC是实现
很多航司，尤其LCC使用NDC的原因，主要还是缺少数据交互的接口规范的参考，应该传递什么，如何传递，传递成什么样子等等。而非真正考虑到NDC对于航司中后台对于数据和业务的划分。如果一个中型的航司，没有电商系统，也许NDC的价值真正能够发挥出来，因为真的可以盲目的按照Data Contract的schema结构定义垂直的数据域和业务Pipeline。
另外单纯一个航司的NDC实现，或较多接口的规范化和标准化，其有多大的价值呢？航司有全套NDC实现后，也需要消费方来使用。也需要哪些消费方能够消费这样的标准。除非大家都实现了NDC，就那几个没实现了。
但是NDC还是有其价值的，但就从IT角度而言，航司PSS和电商内部有很多数据的交互，其实都可以参考IATA的SimpleType和ComplexType的schema定义，优化和规范自身的数据交互规范，其实就是元数据的概念了。这总比航司自己开发团队，而且是很多年纪轻轻的外包开发人员绞尽脑汁设计的schema好不少吧。
