7、微服务设计与边界确定全解析

微服务设计与边界确定全解析

1. 获取 API 规范反馈

在 API 和服务设计中，基于 OAS 描述或其他标准的初始版本是一个重要里程碑，但要设计出优秀的 API，还需进行更多建模工作。我们要将端点的设计草案展示给将使用这些 API 和服务的客户端开发人员，并收集他们的反馈。这一阶段需要我们认真倾听和反思，对于设计出经得住时间考验且受客户端喜爱的 API 和微服务而言，这是极其重要的一步。

关键决策在于收集服务设计的反馈，只有将服务呈现给目标受众，收集反馈并应用到初始设计中，服务设计才算完成。在设计服务和 API 时，通常要考虑两类客户：
- 系统的最终用户，API 为他们实现用户体验。
- 针对服务（API 或微服务）进行编码的客户端开发人员，他们构建最终用户的体验，如 Web 或移动应用。

在 SEED(S) 过程开始时，我们会采访最终用户，收集并理解与他们相关的工作故事。之后，在交互设计阶段以及生成 OAS 之后、编码之前，我们会开始接收客户端开发人员的反馈。必须对 API 客户端开发人员进行采访，以测试设计的可用性，避免因可用性差而导致编码工作被拒绝。这两项研究活动都至关重要，前者确保我们做对的事情，后者确保我们以正确的方式做事。

2. 实现微服务

SEED(S) 方法的最后一步是实现微服务，这一步有意安排在流程的最后。编码是软件工程团队最昂贵的活动之一，重新编码基于错误假设设计的功能是一项可怕、耗时且昂贵的任务。因此，在开始编码微服务之前，我们要采用像 SEED(S) 这样经过深思熟虑的流程，这样总体上可以节省时间并获得更好的结果。

下面通过一个表格来对比 API 和微服务在 SEED