我目前正在为我的公司（物流公司）设计一种微服务方法。现在我们有一个单一的关系数据库的单体系统。
我了解拥有单独数据库的微服务方法。不幸的是，我不明白如何管理不同服务所需的数据。即，在开发票、预订、寻路等方面需要有关地理层次结构的数据。它描述了世界上任何地方的层次结构（即，有一个城镇位于一个位于某个州的县中，该州位于位于某个大陆的国家中）。在我看来，这些数据不属于任何提到的服务，但任何这些服务都需要这些数据。
我该如何处理这种数据？
我可以想象的一个解决方案是为这些数据创建一个自己的微服务，但这不符合领域驱动设计理念，即按功能而不是按服务拆分服务。
谁能帮我？
在决定时，您将要考虑如何更新和更改这些数据。
假设偶尔需要更新这些数据（例如新城镇），管理这些更新的责任对于包含地理层级权威数据库的独立服务来说是一个非常好的候选者。
然后，您可以选择其他服务如何获取他们需要的地理层次结构数据。
他们可以对地理层次服务进行查询，但这意味着该服务的不可用意味着他们无法实现他们的目标。这些服务与地理层次服务深度耦合。
或者，地理层次结构服务可以发布描述地理层次结构变化的事件：其他服务订阅这些事件并更新他们自己的本地模型，其中包含他们完成目标所需的地理层次结构数据。因为这些数据与他们需要的其他数据一起存储，所以它将与他们拥有的其他数据一样可用；地理层次结构下降仅意味着没有更新。Kafka 或 Pulsar 等持久的日志结构存储系统非常适合事件发布。
第二种方法确实需要明确处理最终的一致性（在一段时间内，并非所有服务都同意地理层次结构的当前状态，就像在现实世界中有一段时间有些地图只有一个南斯拉夫和其他国家将拥有斯洛文尼亚/克罗地亚/波斯尼亚/塞尔维亚/黑山/科索沃的一些子集），但是在第一种方法中存在类似的问题（考虑在查询之后但在查询者完成之前发生更新时会发生什么使用结果（进一步：考虑缓存......））被扫到地毯下。
第二种方法的一个优点是，由于地理层次服务只需要进行更新，它不必一直运行。
如果数据几乎永远不会更新，那么也值得考虑将其设为可加载到各种服务中的静态配置数据。这并不能避免最终的一致性问题（除非您愿意在进行更新时使用地理层次结构关闭每个服务），但它可能会节省数据库的成本（无论您存储什么版本控制或配置管理） in 实际上是数据库）。