0.3 真实示例：会议系统案例研究

我们选择了一个会议系统作为我们的案例研究模型，因为这个领域容易被理解，同时也提供了足够的复杂性来建模一个演进架构。图0-1在顶层展示了会议系统，让我们能够设定正在讨论的架构的上下文。这个系统被外部客户用于创建参会者账户，查看可用的会议场次，并预约参会。

图0-1：C4会议系统上下文图

让我们放大到图0-2中的会议系统方框。展开会议系统可以提供更多关于其主要技术构建模块的细节。客户与Web应用程序进行交互，该应用程序调用会议应用程序的API。会议应用程序使用SQL查询后端数据存储。

图0-2：C4会议系统容器图

图0-2揭示了从API的角度来看，最有趣的功能位于会议应用程序容器内。图0-3放大了这个特定的容器，让你可以探索其静态结构和交互方式。

当前系统涉及四个主要组件和数据库。API控制器面对来自用户界面的所有传入流量，并决定将请求路由到系统的哪个位置。该组件还负责把网络格式的数据包转换为代码中的对象或表示形式。从进程内路由和充当连接点或前端控制器模式的角度来看，API控制器组件非常有趣。对于API请求和处理，这是一个重要的模式，所有请求都经过控制器，它决定请求的去向。在第3章中，我们会探讨将控制器从进程中剥离的可能性。

参会者、预订和会议场次组件负责将请求转换为查询语句，并在进程外执行针对数据库的SQL操作。在现有架构中，数据库是一个重要的组件，可能用来强制保障数据间的关系，例如预订和会议场次之间的约束。

图0-3：C4会议系统组件图

既然已经深入足够的细节，让我们重新审视一下案例研究中的API交互类型。