似乎在传统的微服务架构中，每个服务都有自己的数据库，并且对数据的理解不同（此处描述）。有时，数据库复制数据被认为是允许的。例如，“用户”服务可能基本上了解用户的所有信息，而“帖子”服务可能只存储主键和用户名（例如，以便可以显示帖子作者的姓名）。本页讨论数据重复时的最终一致性、事实来源以及其他相关概念。据我所知，微服务架构有时包含共享数据库，但我查看的大多数地方都表明这是一种罕见的策略。
至于为什么每个服务通常都有自己的数据库，到目前为止我所看到的只是“以便每个服务拥有自己的资源”，但我不相信 a) 服务层以任何方式“拥有”持久化的资源首先通过数据库访问资源，或者 b) 服务甚至需要拥有它们所需的资源，而不是通过共享数据库访问主资源的必要子集。
那么微服务架构中的每个服务应该拥有自己的数据库的理由是什么？
我正在开发一个具有以下目录结构的项目：
project/
package1/
module1.py
module2.py
package2/
module1.py
module2.py
main1.py
main2.py
main3.py
...
mainN.py
其中每个mainX.py文件都是一个可执行的 Python 脚本，可从package1、package2或两者导入模块。package1和package2是子包，旨在与项目的其余部分一起分发（而不是独立地）。
标准的做法是将入口点放在顶级目录中。我有N个入口点，所以我把它们都放在顶级目录中。问题是 N 不断增长，所以我的顶级目录被入口点淹没。
我可以将mainX.py文件移动到子目录（例如，project/run），但是所有的package1和package2导入都会中断。我可以将package1和提取package2到一个单独的存储库，并期望它安装在系统上（即，在系统/用户 python 路径中），但这会使安装复杂化。我可以作为前提条件或在运行时修改 Python 路径，但这很混乱，并且可能会带来意想不到的后果。我可以编写一个main.py入口点脚本，其中参数子解析器分别指向run/main1.py, ..., run/mainN.py，但这会引入main.py每个run/mainX.py文件之间的耦合。
这个问题的标准“Pythonic”解决方案是什么？