在 Api 后面构建 Web 应用程序功能

Question

我必须准备一份规范，为开发人员构建内部项目提供路线图。 该项目将包括一个网络应用程序和一个移动应用程序。 移动应用程序将用于收集用户反馈，通常移动应用程序应显示几个问题供用户回答。

示例问题如下所示；

1. 你用鞋油擦鞋了吗？
2. 你晚上看新闻了吗？

捕获的数据将被发送到一个sql server。

网络应用程序用于将问题发布到移动应用程序，网络应用程序也应用于查看报告。 该网络应用程序应具有以下功能； 1. 将调查发布到移动应用程序，这可以通过 MQTT、AMQP 或类似协议完成。 2.以图表形式查看数据 3. 管理设备，例如注册新的移动设备等

需要什么 这个项目将被分到3个团队，后端团队（Api团队），前端团队和移动开发团队。 后端的功能应该进入一个Api，前端应该始终与后端对话以获取数据，基本上不允许业务逻辑进入事物的前端。前端只会写 css/html/js 来做标记和展示，其余的功能应该通过 Api 来使用。

我必须写一个项目应该如何实现的详细规范，后端将用 PHP 和 Symphony 实现。前端可以是任何 JavaScript 框架，移动应用将在 Android 中实现。

你能知道我应该如何对后端（Api）进行建模，以便它包含 Web 应用程序所需的所有功能吗？ 最重要的是，在 api 之上构建功能是这个项目的好策略吗？我是否应该采用将前端和后端连接在一起的整体方式（这将使一名开发人员在前端工作而另一名开发人员在后端/api 工作变得困难）？

Answer 1

这是一个完美的 CQRS 后端应用程序，由队列提供。借助 CQRS，后端的写入端和读取端被分离为不同的 API，这在将项目拆分到多个团队时尤其有利。

CQRS 的主要思想是有一个 API 可以对数据进行任何更改，并且通过命令对数据进行更改，然后通过命令将其持久化到规范化的数据库中。还有一些定制的物理表，用于包含单个视图所需的所有数据（这些表是非规范化的）。每次将数据写入聚合时，相应的视图模型也会更新。这导致了一个结构，其中写入端很复杂，但具有所有业务逻辑和规则，而读取端非常简单，基本上只是从适当的视图模型表中执行“select *”查询。只要读取模型（也称为投影）保持最新，读取速度就会快得多，并且由于大部分数据库访问是读取，因此整个站点会更快。

在您的情况下，我将创建 3 个 API——一个用于移动前端的读取模型，一个用于 Web 前端的读取模型，一个用于命令端。这样，移动人员可以灵活地构建他们需要的东西，并且他们可以在开发过程中根据需要更改读取模型表设计以满足需求。 Web 人员也可以做同样的事情，后端团队实现了困难的东西——命令、业务规则、规范化的表结构等。合并这三个项目需要让其中一个团队创建查询来更新视图模型表。实体表。

如果您引入基于事件的通信架构，即事件驱动架构，这一切都会变得更加容易。这将进一步解耦这 3 个不同的关注点，并使它们在以后更容易合并，因为每个微服务都会订阅适当的消息以接收更新和新的缓存信息。