我有3种不同的服务需要访问同一个数据库。这些服务中的每一项都将用于不同的目的和不同的查询我可以按照以下方式概括它们
我写了一个DAO来公开数据。我正在评估两个系统设计的可扩展性和维护。
选项1：再写一项服务，将DAO功能公开为数据服务。
优点：
- 将控制数据库上的负载，并根据需要轻松扩展/缩小
- 易于维护以备将来更新
- 各种行动的访问控制
- 客户对基础数据库没有完全访问权限
缺点：
- 单点故障
- 额外服务管理
- 需要强制执行向后兼容性规则
- 如果DataService停机，每个服务都会受到影响（数据库停机时间以外的因素）
并且
选项2：从DAO创建存储库，并在上述三种服务中使用这些库。
优点：
- 分布式，冲击半径非常小
缺点：
- 每项服务都可以获得对数据库的完全访问权限
- 需要更新所有三项服务以获取新功能
答案 0 :(得分：1)
这是一种意见......当需要对数据库进行共享访问时，我们使用选项1。封装使我们能够支持向后兼容的服务调用，这使我们能够更多地重用我们的服务。管理开销较高，但如果您获得了非常少量的客户端服务，那么值得控制访问的能力。
想想您是否有数十个应用程序中使用的10-20个服务。如果您需要重构数据库（这将会发生），更新所有这些应用程序以及同步其部署的成本是巨大的。此外，正如您所说，缓存等内容可以集中完成，并可以在集中式服务中轻松扩展。分布式缓存失效是一个棘手的问题，最终成本远远超过了通过集中访问来首先避免问题。
这只是我的经历。因人而异。如果您的数据库架构非常静态，那么您可能无法获得同样多的好处，或者您不希望出现许多扩展问题。就像我说的那样，这是一种观点。
答案 1 :(得分：1)
首先，我会为每个服务构建单独的DAO，因为它们都有不同的bounded contexts，来自您的描述。例如，最有可能的是，“服务3 - >报告”将是用于提取聚合数据的只读服务，并且它不应该知道订单处理器和客户查询的内容。另外，如果您期望大量数据，请考虑为报告查询使用单独的数据库，因为对于一个数据库来说可能负载太大，并且更容易扩展它。 关于您关于公开数据的服务的问题，对于每个服务使用单独的DAO，我认为最好将DAO放在lib中。这样，每个服务只能访问它所需的数据，如果只需要对一个DAO进行更改，则不必部署所有服务。此外，您可能希望使用基本DAO来封装很少更改的公共逻辑。请记住，除非将服务部署到与数据库相同的计算机上，否则使用服务公开数据将为数据添加一个层，直到它到达数据库。它对于高性能应用程序可能至关重要。
答案 2 :(得分：0)
感谢Rob和Maksym的投入。
我根据有界上下文分离了查询，并为不同的上下文创建了库和服务。
查询和订购服务使用数据服务访问数据。这有助于我控制嘈杂的邻居和资源分配。
我将数据从主数据库复制到报告数据库，并为报告服务构建了一个库来访问报告数据库。