2.3.3 设计架构和业务中心

规划方案和分析需求后，就进入整体技术架构和业务中心的设计阶段：一方面分析所有收集到的业务需求，从中找到可以复用的共性业务功能，将它们从逻辑上划分为一个个业务中心；另一方面是有了这些业务中心概念后，应考虑如何快速敏捷地实现，具体需要完成的任务大概如下。

1.建立业务领域模型

业务领域模型是对企业每个业务模块的功能、该业务模块与其他业务模块的关系及业务边界的描述。上文我们已经找到了旅客服务域的3个实体是旅客、行李和行程（航班）。按照阿里的中台建设步骤，接下来应该对这3个领域实体进行细化，识别出周边所有相关的实体，基于实体再进行业务流程最优化为目标的用例图和时序图的设计，最终完成整个系统完整的业务领域模型。

我中台建设时并没有按照这种方式进行设计，这是一种用户驱动的方式，需按用户的需求去设计和匹配后台的数据和能力，这对于一个几十年的传统国有企业来说要求太高了。如果是互联网企业或从无到有、从简单到深入的新业务领域，按上面的方式完全是合适可行的。但甲方达不到这样的技术积累要求，也没有能力从这样的高度进行业务领域模型的抽象，而且机场行业对数据的依赖非常强，在数据层面完成不了闭环，为了系统的安全稳定，很多核心系统很难按用户的需求去调整升级，大多数情况都是以现有的、能获取到的数据为基础去做服务和应用系统。

基于企业自身的IT条件和数据环境进行调整，确定以数据为驱动，从后台给前台提供能力和数据并结合用户的响应，虽然不先进、不完美，但更容易落地。

2.建立业务数据模型

业务数据模型驱动和业务领域模型驱动没有本质的区别，也需要找业务实体、找实体关系、划分业务边界，只是业务领域模型驱动是从用户需求侧开始找，业务数据模型驱动是从后台数据侧开始找。也许两种方式产生的结果一样，但根据我个人的经验就算结果不一样，也只是粒度上的区别。业务数据模型驱动也许并不适合各位读者的具体情况，但我本人做过多年数据仓库和大数据平台的开发，对数据模型更熟悉，有了感情。我的判断依据是为了满足用户的价值需求，如果可以不太难地调动后台各种资源进行调整和升级，可以用阿里推荐的业务领域模型驱动进行设计；如果是技术和业务协调难，就建议用传统的业务数据模型驱动来设计。但这里也有个问题，承建方的业务中台设计人员一般更熟悉领域建模，而数据建模一般是数据中台的设计人员更擅长的，如果能碰到一位既懂业务应用又懂数据模型的设计人员就最完美了。

业务数据模型主要描述实体的关联关系，并不需要进行表设计及字段的设计，这些是在具体开发阶段完成的，图2-18所示为旅客服务域的业务数据模型。

图2-18中只画了3个领域实体的细化和扩展，后面开发demo以实现这3个业务中心为例。旅客实体有自己的账号和会员信息，旅客如果坐飞机就有他的行程信息，如航班、时间、出发目的地等，有行李的旅客又会是行李实体。出行时机场会依据旅客的航班行程、行李等提供相应的服务产品给旅客，这些服务通过后台的流程驱动去实施，每个流程节点都需要相关的保障人员去执行，服务过程中需要和旅客建立沟通渠道和保持信息的传递，旅客在出行中咨询的问题可通过机场的知识库进行智能回复。

3.建立业务中心

业务领域模型或业务数据模型设计好后，实际上各业务中心就已经基本设计出来了。业务中心和模型最好一一对应，就是在业务数据模型的基础上加了业务中心的概念。

业务中心初期不要设计太多。我们曾在设计阶段设计了10个业务中心，逻辑结构清晰，业务流程顺畅，但在开发阶段才发现多个业务中心导致工作量和开发量成倍增长，有太多的依赖关系。调用复杂而且还涉及分布式事务一直没有好的解决办法，所以在开发阶段又回过头来进行了业务中心的梳理合并，但合并一定要有强依赖的关系，有统一的出口。

4.设计业务中心的依赖关系

这个步骤最好找一个业务应用场景进行依赖关系的设计，可以通过时序图表示。为了更容易说明业务中心的交互关系，以旅客中转行李应用为例，如图2-19所示。中转旅客在机场申请行李免提，按行李免提的场景组装业务中心的相关能力。

1.在旅客中心找到旅客的证件号码等个人信息和联系方式。

2.通过证件号码在行程中心查旅客的行程及航班实时状态。

3.通过旅客的行程在行李中心查旅客的行李及实时状态。

4.在产品中心定义行李免提产品以及相关的服务规则，如什么旅客、什么样的行程可以享受什么样的服务。

5.如果行李超重或没有免费行李额，则使用支付中心的聚合支付和清分结算能力。

6.通过订单中心进行线上和线下的服务流转，使用订单进行业务的驱动。

7.在整个服务过程中旅客可以通过评价中心对服务产品和订单进行投诉或评价。

8.旅客非常关心自己行李的实时状态，通过消息中心实时与旅客交互，推送最新的行李运输进度。

从图2-19可以看出一个业务应用是基于中台的业务中心串联起来的，从服务的提供和数据的支持一目了然。需要注意的是中台实施初期要明确有哪些应用应在中台实现，哪些应后期在中台逐步实现。建议在核心流程上能覆盖所有业务中心能力的应用先实现，应用的个数不能太多。

5.设计各业务中心的服务能力

服务能力是中台的核心功能，向下整合、向上共享复用就是对业务中心服务能力的共享复用。从图2-19中就可以抽取出各业务中心针对的中转应用的服务能力目录，相应的其他业务应用也用一样的方法进行服务能力目录的完善。这里的设计能力非常考验架构师的水平，因为之前已经把业务数据模型设计出来了，现在需要每个服务能力去业务中心的业务数据模型里找数据。这是个抽象的过程，而且要把每个业务应用场景用到的每个业务中心能力进行梳理设计。如有3个业务应用场景：旅客中转应用、航班延误应用、贵宾服务应用，它们都涉及用户的登录，但登录场景可能不一样，有的需要密码登录，有的需要验证码登录，还有第三方应用如微信、支付宝授权登录等，都需要架构师进行统一设计服务能力，再如中转旅客和贵宾旅客在会员中心的业务能力也是不一样的，贵宾里可能还有要客，他们和普通的贵宾服务又不一样。这样的会员中心的服务能力目录应该如何设计呢？表2-1为用户登录的用户中心能力目录的一部分。

读者应该都能看明白前面几列的意思。用户中心的能力目录分为上、下两级进行组织，每一个服务能力只能属于一个一级分组和一个二级分组，每个一级分组可以包含多个二级分组，每个二级分组又可以包含多个服务能力，每一个服务能力实际上就是一个业务接口，需要进行接口编号以及详细的说明。

最后两列是全局事务服务（Global Transaction Service，GTS）和性能测试服务（Performance Testing Service，PTS）。GTS是标注出此服务能力接口是需要保证分布式事务的，如删除账户，不仅要把账户本身删除，还要保证把相关的证件信息、车辆信息、发票信息等都删除，如果有一个删除失败则整个服务需要回滚到初始状态。在微服务分布式环境下要实现这样的功能还不是太容易，我们没有能力研发分布式事务，所以使用了阿里云的分布式事务产品GTS解决。PTS标注的服务能力接口是需要进行压力测试的，如用户通过openID获取自己的微信账号信息的服务能力，这个接口在日常的业务应用中使用量会非常大，而且要依赖第三方应用微信的接口，在设计阶段就需要考虑进去。