数据库读写职责的分离

Question

我们正在研究一个报告系统，它有清晰的写入和读取路径。例如，只有在使用来自队列的事件之后才会发生写操作，而只有在为来自API的请求提供服务时才会发生读。职责不太可能混在一起，即向DB写入的服务不会使用API使用的查询，反之亦然。

代码真的很长(因为java)，可能会让一个新的人感到困惑。我正在考虑将DB分为两个类，ReportingIngestDBClient与ReportingReadDBClient之间没有关联的名字。

我在想：

• ( 1)有人遵循这一模式吗？这让事情变得更清楚了吗？如果是的话，你用了什么名字？
• 2)如果您没有遵循创建两个单独的对象来处理不同查询的模式，您是否有强烈的反对意见，以及为什么？

Answer 1

正如Laiv在他的评论中所指出的，您应该看看CQRS设计模式。让我在这里详述一下。

CQRS代表命令查询责任隔离。其基本思想是将您的数据访问代码划分为两个截然不同的类别：

查询:返回结果，不更改系统的可观察状态(没有副作用)。

命令:更改系统的状态，但不返回值。

下面是一些关于CQRS设计模式的文章：

1. 马丁·福勒- CQRS
2. 格雷格·杨- CQRS，基于任务的UI，事件源agh！
3. Udi大汉- 澄清的CQRS

Answer 2

每次添加结构时，您也会减少灵活性，因此一般来说，您应该只有真正需要的足够多的结构。我认为这种分离并不是真正必要的，更多的灵活性会更好。

我也会从这个角度来看待这个问题。封装的目的之一是通过将知识(业务逻辑)隔离到系统的一个部分来简化代码。如果您有单独的读写数据库，您应该尽量减少软件中需要了解这一点的位置。

数据访问层理解双数据库设计似乎是很自然的，但是如果将数据访问划分为两个类，那么系统的许多其他部分需要了解这种设计，因为它们必须根据数据库是否更新来决定应该调用哪一个数据层。要让应用程序的其他部分知道数据库是否得到更新，就意味着要对数据库的具体工作方式有详细的了解--这是一种耦合。

总之，如果您创建了两个类，那么这些类的使用者需要对数据库设计有足够的了解，以便正确地选择使用哪个类，这会在数据库设计和数据层的使用者之间建立耦合。数据层应该对这些使用者隐藏这些细节。