在标准的微服务架构中，每个服务都负责设置边界的自己的数据。操作此数据的唯一方法是通过服务提供的RESTful端点。
我有一个独特的案例，我希望运行一些集群刮刀进程，用原始数据填充表。这些刮刀过程也可以针对特定情况进行配置，例如一个用于刮取文本，一个用于刮取图像等。
然后，原始数据将被另一个进程消耗并聚合到另一个表中的规范化结构中。我想将所有这些流程拆分为可部署的小型组件，但这意味着我必须以某种方式在多个存储库/项目中共享模型定义，因为聚合逻辑必须使用所有原始数据。
聚合逻辑可能会向每个集群化的scraper进程发出请求，但是对它的状态控制比查询表要复杂得多。
我知道可以在隔离的仓库中定义模型定义，然后在其他项目中作为依赖项导入，但这是正确的架构吗？
答案 0 :(得分：1)
何时使用微服务的最佳情况是，在问题域中有非常明显的有界上下文。当你有像你所描述的场景一样重叠的上下文边界时，微服务可能会比你获得更多的成本。尽管存在这个问题，您是否觉得通过将应用程序解构为微服务来获得生产力？ 如果没有更好地了解您的应用程序，很难给出明确的答案，但是当您在开始时遇到这样的问题时，很可能这对于微服务架构来说不是一个好例子。请记住，这只是我的两分钱。 共享物理存储库以进行配置听起来非常繁琐，如果可能的话我会避免使用它！