拆分和命名微服务

时间:2016-11-19 09:07:16

标签: soa microservices

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

面向服务的体系结构(或微服务)听起来像是一个很好的方法来做到这一点。我面临的问题是如何决定,我的项目的哪些部分属于一个单独的服务以及如何命名它们。

采取项目的以下部分:

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

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

这是一种有效的方法,还是应该将第一项服务分成更小的部分?你如何命名这些服务?

1 个答案:

答案 0 :(得分:3)

Eric Evans在GOTO 2015大会上(https://youtu.be/yPvef9R3k-M)和我100%同意他,回答了你的问题。微服务范围应该是一个或多个有界上下文。包括其持久性支持类,REST / HTTP API等。 据我所知,微服务是Bounded Context上的部署包装器,增加了隔离,扩展和弹性方面。 正如您所写,您没有应用战略设计来定义有界上下文。所以是时候检查一下,然后将应用程序撕成碎片。