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