我必须准备一个规范，为开发人员提供一个构建内部项目的路线图。 该项目将包括一个网络应用程序和一个移动应用程序。 移动应用程序将用于收集用户反馈，通常移动应用程序应显示几个问题供用户回答。
示例问题如下所示;
- 你用鞋油清洁鞋子了吗？
- 你晚上看新闻了吗？
捕获的数据将发送到 sql 服务器。
Web 应用程序应用于将问题发布到移动应用程序，Web 应用程序也应用于查看报告。 网络应用程序应具有以下功能; 1. 将调查发布到移动应用程序，这可以通过 MQTT、AMQP 或类似协议来完成。 2. 以图表形式查看数据 3. 管理设备，例如注册新的移动设备等
需要什么 该项目将被吐槽并分配给3个团队，后端团队(Api团队(，前端团队和移动开发人员团队。 后端的功能应该进入 API，前端应该始终与后端通信以获取数据，基本上不允许业务逻辑进入事物的前端。前端只会为标记和演示编写css/html/js，其余功能应该通过API使用。
我必须编写一个详细的规范，说明项目应该如何实现，后端将在PHP中实现。前端可以是任何JavaScript框架，移动应用程序将在Android中实现。
你能不能如何对后端(Api(进行建模，以便它包含Web应用程序中所需的所有功能？ 最重要的是，在 api 之上构建功能是这个项目的好策略吗？我是否应该采用整体式的方式，将前端和后端连接在一起(这将使一个开发人员很难在前端工作，另一个开发人员在后端/api上工作(？
这是 CQRS 后端的完美应用程序，由队列提供。 使用 CQRS，后端的写入端和读取端被分成不同的 API，这在多个团队之间拆分项目时特别有利。
CQRS 的主要思想是，只有一个 API 对数据进行任何更改，并通过命令对数据进行更改，然后由命令保存到规范化数据库。 还有一些自定义的物理表，旨在包含单个视图所需的所有数据(这些表是非规范化的(。 每次将数据写入聚合时，相应的视图模型也会更新。 这导致了一个结构，其中写入端很复杂，但具有所有业务逻辑和规则，而读取端非常简单，基本上只是从适当的视图模型表中执行"select *"查询。 只要读取模型(也称为投影(保持最新，读取速度就会快得多，并且由于大多数数据库访问都是读取，因此整个站点都会更快。
在您的情况下，我将创建 3 个 API – 一个用于移动前端的读取模型，一个用于 Web 前端的读取模型，一个用于命令端。 这样，移动人员就可以灵活地构建他们需要的东西，并且可以在开发过程中根据需要更改读取模型表设计以满足需求。 Web人员也可以这样做，后端团队实现困难的东西 - 命令，业务规则，规范化的表结构等。 合并这三个项目需要让其中一个团队创建查询以从实体表更新视图模型表。
如果您引入基于事件的通信架构，即事件驱动架构，所有这些都会变得更加容易。 这将进一步分离 3 个不同的关注点，并使它们以后更容易合并，因为每个微服务都会订阅适当的消息来接收更新和新的缓存信息。