任何人都可以帮助您更好地了解它。
我们正在使用微服务架构开发应用程序。现在我们有了不同的结构。
基于功能，我们制作了不同的微服务。
现在我们被一分挡住了。
除了不同的Actor，我们还有“管理”或“客户服务”用户。
从他们那里，我们有一些特定的APIS。
我们对此有疑问。
1) Do we need to consider creating different micro service project.
2) Assume we consider different micro services, do we need to share all the domain models to this micro service.
3) Assume, we keep Admin or Customer Service APIS in respective Micro services, how good it is. my point is about exposing or potential to expose Admin API to the world.
答案 0 :(得分：1)
1）我们是否需要考虑创建其他微服务项目。
如果您的数据可以迁移到微服务架构，那么是的，您应该考虑微服务架构。
3）假设，我们在各自的Micro中保留了Admin或Customer Service APIS 服务，它有多好。我的观点是关于暴露或潜在 向世界展示Admin API
恐怕您是从错误的角度看待这个问题。用户的角色不应是驱动微服务设计的角色。相反，它应该是您的数据/实体/域。重击的规则是，对于不同的微服务，数据存储区应该有所不同。
2）假设我们考虑了不同的微服务，是否需要共享 该微服务的所有域模型。
我想在上一个之后回答这个问题。如果正确设计微服务，则域重叠将是最小的，相应地，需要共享的代码（域POJO）也将是最小的，但这仍然不是完全可以避免的。分享代码有一些创造性的方法
将包含所有共享代码的库jar文件发布到内部存储库中，并在您的主要项目中引用
有一个包含所有微服务的父项目，以便您可以共享代码。 （恭喜，您刚刚创建了一个整体代码库：））恕我直言，恕我直言，这违背了微服务的精神。即使您仍可以将每个微服务部署为单独的应用程序/ jar文件，但代码库仍是整体的）
一个小建议是，不要挂在代码共享能力上。如果您决定使用go / rust之类的非JVM语言编写其他微服务怎么办。毕竟，那是微服务架构的主要卖点之一。