最后，横向划分模块对于问题的追踪调试也不友好，几乎每次事故调查总是要穿插涉及在几个团队之间不停的协调开会，因为一个完整业务流总是要贯穿前后几个层的功能。

需要指出的是，端到端划分服务并非是说服务与服务之间都是平级的。实际上，服务之间可以再聚合成更高层级的组合服务的，以及在最顶端的API Gateway也可以算是一类服务。只不过，在核心业务层的这些服务，每个都单独提供了某项特定的业务价值。

识别核心业务服务

微服务的架构通常并非是一开始就重头设计出来的，而是先有整块的单体架构，随着业务的复杂度上升，才逐步拆分出来。业务领域建模除了能用来指导适当的服务划分，另一个重要的作用是让工作聚焦到核心的业务服务中。

无论多复杂系统都是为特定业务价值而存在的。在系统的实现中必然会存在与核心业务最相关的部分、辅助核心业务的部分、和非核心业务关系的部分。它们在领域驱动设计的术语中称为“核心域”、“支撑子域”和“通用子域”。在进行领域建模的时候就应该顺便识别出系统里的关键领域。将系统的业务领域罗列出来然后划分出重要性，这件事情听起来似乎是多此一举，甚至有点荒唐，但对于复杂系统，实际去做这件事带来的价值可能远比它看起来更大。

首先，当我们将一个复杂的系统的各种业务仔细清点到台面上以后，得到的列表往往会比许多人最初想象得长得多，它能提醒我们系统的复杂度是否已经过高了。其次，列举业务的过程也是开发者与业务人员沟通的过程，来自不同业务线的代表也许会为某部分业务的价值点发生争执，或是提供一些许多开发人员此前并不了解的细节信息，将这些问题当面讨论清楚并非什么坏事。此外，当我们真的去仔细思考一个业务系统的核心价值时，也许会得出使人意想不到的结果。

继续举例子，在汽车的销售和售后平台中，通过业务建模，可以划分出许多子领域：

• 在线购车（渠道A）

• 在线购车（渠道B）

• 在线购车（渠道C）

• 试驾预约

• 售后服务

• 用户反馈

• 订单系统

• 促销活动

• 车辆市价信息

• 车辆参数信息

• 4s店信息

• 用户信息管理

• …

说明：这里渠道指的是销售平台对接的一个第三方系统，其中每个渠道可以对应多个汽车品牌

然后我们要从中识别出业务中的核心域。必须强调，服务领域划分仅仅是代表服务对系统关键业务贡献的价值，处于核心域中的那些服务应该是该系统业务成功的主要促成因素，从战略层面讲，企业应该在自己的核心领域上具有一定壁垒优势。经过讨论，开发者和业务人员最终得出让人大跌眼镜的结论，核心域部分的服务只有“试驾预约”和“售后服务”，因为这两项才是该企业最具竞争力的业务。而看起来十分重要的“在线购车”服务，由于并不具有特别的行业竞争优势而被划到了支撑子域中。正确的服务划分定位将对系统未来的发展策略产生积极的影响。

在这个系统中的“车辆市价信息”、“车辆参数信息”、“4s店信息”等服务都被划归到了通用子域。在通用子域中的服务并非最没有价值或是复杂度最低，而只是说明系统在这些服务领域中通常不具优势，因此这部分功能完全可以考虑外包开发或者购买第三方的现成服务。

使用符合业务结构的API

前面介绍业务建模的时候我们强调了使用“API集成”的必要性，以及它的反面形式“数据库集成”所带来的问题。在微服务的架构中，服务的技术选型可能是异构的，API的实现也会各有不同。除了Web应用比较流行的RESTful标准，还有像SOAP、ProtolBuf、MessageQueue等不同的协议与格式标准，它们都可以被作为服务之间通信的API。不同的API设计对服务使用的体验差别会很大，除去技术原因对API协议的倾向性，在设计和评价API方面依然有许多值得注意的地方。

一个好的API设计应该在接口的元数据中向用户提供尽可能多的有意义的业务信息，这里指的元数据包括例如API的名称、参数、标签等等用户在不需要专门查看文档就可以看到的内容。通常在各种不同的API协议里，总会存在一个相似的概念，就是目标路径。比如RESTful的URL地址，ProtolBuf的消息类型嵌套结构，MessageQueue名称里用斜线划分Topic路径的惯例等。以RESTful标准为例，可以试比较下面两种URL地址的差异。

• 第一种：/users/123/orders/123

• 第二种：/orders?id=123&user_id=123