这就是聊天服务器。毕竟，它不会很复杂。在开始编码之前还有很多工作要做，但是对于本文来说已经足够了。
客户端
这是最后一个需要编码的模块，它将是最笨重的一个模块。根据经验来看，我更喜欢让客户端笨重，使服务器轻巧。这样为服务器开发新的客户端会更加容易。
这是我们最终应该采用的架构。
最终架构
我们要实现的ClI客户端很简单，不会实现任何非常复杂的东西。实际上，必须要解决的最复杂的部分是 UI，因为它是一个基于文本的界面。
客户端应用程序必须实现的功能如下：
- 创建一个新游戏。
- 因为我希望尽可能保持简单，所以这只能通过 CLI 界面完成。实际用户界面只会在加入游戏后被用到，这把我们带到下一个问题。
- 加入现有游戏。
- 玩家可以根据由上一条返回的游戏编号来加入游戏。另外，这件事应该能够在没有 UI 的情况下完成，因此这个功能将成为开始使用文本 UI 所需的过程的一部分。
- 解析游戏定义文件。
- 我们将对这点进行的讨论，客户端应该能够理解这些文件，以便能够理解要显示的内容，并知道应该如何使用这个数据。
- 与冒险互动。
- 基本上，这使玩家能够在任何时间与给出描述的环境进行交互。
- 为每位玩家维护背包内容。
- 客户端的每个实例都将在内存中包含一份道具列表。此列表将被备份。
- 支持聊天。
- 客户端程序还需要连接到聊天服务器，并使用户登录到组队的聊天室。
稍后将详细介绍客户端的内部结构和设计。与此同时，让我们完成设计阶段的最后一部分：游戏文件。
游戏：JSON文件
这是它变得有趣的地方，因为到次为止，我已经涵盖了基本的微服务定义。其中一些可能会基于 REST，而另外一些可能会使用套接字，但本质上它们都是一样的：你定义并对它们编码，然后它们提供服务。