假设我在不同的微服务中有两个实体(聚合根(。
- 报告(id，status=opened|in_progress|processed|closed，follow_up(自定义表单答案(，investigation(自定义表单回答(，…(
- 检查(id、form_answers…(
我需要添加一种可能性，以便在这些实体的生命周期中填写自定义(动态(表单。
表单由用户创建，不能在"检查"中填写特定于报告的表单，反之亦然。表单结构(字段类型(和表单提交(答案(模型在这些实体之间是相同的。
我的问题是，考虑到以下领域限制，如何以微服务的方式设计它：
- it在处理状态下，必须不能编辑Report follow_up，某些特定用户除外
- 当报表关闭时，不能编辑报表follow_up
- 必须只有在处理报告时才能填写调查
- 表单字段对于使用自定义表单的每个实体都应该相同
方法#1
在每个服务中引入一个表单实体，并将答案分别存储在报告/检查中。
优点：
- 状态一致性(更改表单答案的状态检查是在一个集合中完成的，因此更容易遵循域约束(
缺点：
- 代码重复(回答验证/实体结构/…(
- 添加新的字段类型需要更改多个服务
方法#2
引入一个新的表单服务来存储用户定义的表单和表单答案。实体应仅通过id引用答案。
优点：
- 在一个地方形成逻辑
缺点：
- 如果没有紧密耦合或大量传奇故事，很难遵循域约束
我会给出一个通用的答案：
一个好的微服务基础设施更多的是解决特定业务问题的服务，而不是数据库的接口——这是一个常见的错误——服务实际上看起来像是数据库查询的代理。
让我从你的描述中提取服务理念：
- "表单由用户创建"：FormCreationService
- FormFillInService
- ReportsService-它将有一个状态机来确保只允许正确的转换(例如，完成后不进行编辑(
- InspectionService-也带有状态机
下一步将描述每项服务的API(请在youtube上找到"设计API"的视频，这是谷歌非常古老的话题(。
然后，您通过序列图验证api——因此，您可能会合并服务——以防它们太小；或者分割较大的块。
在一天结束的时候，你想将Unix哲学应用于你的服务：；做一件事，把它做好"。