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

Question

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

例题如下；

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

捕获的数据将发送到sql服务器。

网络应用程序用于向移动应用程序发布问题，web应用程序还应用于查看报告。web应用程序应具有以下功能: 1.向移动应用程序发布调查，这可以由MQTT、AMQP或类似协议完成。2.以图表形式3查看数据。管理设备，如登记新的移动设备等。

所需要的这个项目将被分配给3个团队，后端团队(Api团队)，frontEnd团队和移动开发团队。后端的功能应该进入Api，前端应该总是与后端对话以获取数据，基本上不允许业务逻辑进入事物的前端。前端只会为标记和表示编写css/html/js，其余的功能应该通过Api使用。

我必须写一个详细的说明项目应该如何实现，后端将用PHP实现的交响乐。前端可以是任何JavaScript框架，移动应用程序将在Android中实现。

你能不能，我应该如何建模后端(Api)，以便它包含所有所需的功能，在网络应用？在此基础上，在api之上构建功能是该项目的一个好策略吗？我是否应该将前端和后端连接在一起(这将使一个开发人员很难在前端工作，另一个开发人员在后端/api上工作)？

Answer 1

这是一个由队列提供的CQRS后端的完美应用程序。使用CQRS，后端的写入端和读取端被分离为不同的API，这对于在多个团队中拆分项目特别有利。

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

在您的示例中，我将创建3个APIs -一个用于移动前端的Read Model，一个用于web前端的Read Model，另一个用于命令端。这样，移动人员就可以灵活地构建他们需要的东西，并且他们可以在开发过程中根据需要更改read模型表设计，以满足需求。Web人员也可以这样做，后端团队实现了硬内容--命令、业务规则、规范化表结构等等。合并这三个项目将需要其中一个团队创建查询，从实体表中更新视图模型表。

如果引入基于事件的通信体系结构(即事件驱动体系结构)，那么所有这些都会变得更加容易。这将进一步分离3种不同的关注点，并使它们以后更容易合并，因为每个微服务都会订阅适当的消息来接收更新和新的缓存信息。