微服务的拆分和命名

Question

我最近开始了一个业余项目。它应该是一本虚拟的食谱书，具有存储和检索食谱 (CRUD)、对其进行评级和搜索的功能。这不是什么新鲜事，但我想将其构建为桌面应用程序，以了解有关数据库、单元测试、UI 等的更多信息。现在核心域已经基本完成（我使用 DDD 方法）并且我实现了大部分 CRUD 存储库，我想通过在线托管核心功能来使其更具可扩展性，因此我能够编写多个后端（桌面应用程序、Web 应用程序、Web API 等）。

对我来说，面向服务的架构（或微服务）听起来是一个很好的方法。我面临的问题是如何决定项目的哪些部分属于单独的服务以及如何命名它们。

采取该项目的以下部分：

• 核心领域（聚合、实体、值对象、逻辑）-> Java
• 持久性（DAO、存储库、多个数据库后端实现）-> Java
• 搜索（在持久性数据库上使用 SQL 查询进行搜索的搜索服务）-> Java
• 桌面应用程序 -> JS (Electron) 或 JavaFX
• Web 应用程序 -> Flask 或 Rails
• Web API（使用 REST 管理、评分、搜索食谱）-> ?

我最初的方法是将核心域、持久性、搜索和 Web API 放入一个子项目中，并将整个堆栈托管在 Heroku 或类似的东西上。这样我的客户就可以使用网络界面。桌面应用程序和 Web 应用程序本身就是不同的项目。如果 Dektop 应用程序都是用 Java 编写的，则它们可以共享核心域。

这是一种有效的方法，还是我应该将第一个服务分成更小的部分？您如何命名这些服务？

Answer 1

Eric Evans 在 GOTO 2015 会议 ( https://youtu.be/yPvef9R3k-M ) 上回答了你的问题，我 100% 同意他的观点。微服务范围应该是一个或多个有界上下文。包括它的持久性支持类、REST/HTTP API 等。据我了解，微服务是有界上下文上的部署包装器，并添加了隔离、扩展和弹性方面。正如您所写，您没有应用战略设计来定义有界上下文。因此，在将应用程序撕成碎片之前，是时候进行检查了。