如果我要创建一个基本的个人会计系统（因为我就是这样 - 这是一个关于我足够熟悉的领域的爱好项目，以避免陷入需求），像 RavenDB 这样的 NoSQL/文档数据库会是存储帐户的好人选，更重要的是，存储针对这些帐户的交易？如何选择哪个实体是“文档”？
我怀疑这是其中一种情况，实际上是 SQL 数据库是正确的选择，而尝试使用 NoSQL 是错误的，但是当我想到我对 CQRS 和事件溯源知之甚少时，我想知道实体/文档是否是实际上是Account，事务是针对它存储的事件，当这些“事件”发生时，也许我的应用程序也会写入一个易于查询的读取存储，如 SQL 数据库。
提前谢谢了。
个人认为这是一个好主意，但我有点偏见，因为我的全职工作是建立一个基于 CQRS、Event Sourcing 和文档数据库的会计系统。
原因如下：
事件溯源和会计基于相同的原则。你不删除任何东西，你只修改。如果您添加了错误的交易，您不会将其删除。您创建一个抵消交易。事件也是如此，您不要删除它们，您只需创建一个取消第一个事件的事件。这意味着您发布了大量的 TransactionAddedEvent。
接下来，如果您进行复式记账，记录交易与您在屏幕上（尤其是在资产负债表中）查看交易的方式不同。因此，我再次喜欢 cqrs。我们可以使用正确的会计原则存储数据，但可以优化我们的读取模型以按照您希望的方式显示数据。
在资产负债表中，您希望查看给定帐户的所有条目。您不想看到交易，因为交易有两个方面。您只想查看影响该帐户的条目。
因此，在您的文档数据库中，您将拥有一个条目集合。
这使得查询非常容易。如果您想查看一个帐户的所有条目，只需说 SELECT * FROM Entries WHERE AccountId = 1。我知道这是 SQL，但每个人都理解这个查询的简单性。在文档数据库中同样容易。另外，这将是闪电般的速度。
然后，您可以使用按 accountid 分组的查询创建资产负债表，并设置日期限制。请注意，根本不需要连接，这使得文档数据库成为一个不错的选择。
您当然可以创建这样的系统。在这种情况下，您拥有 Account Aggregate，并且还拥有 TimePeriod Aggregate。时间段通常是一个月、一个季度或一年。在每个 TimePeriod 内，您都有该期间的事务。这意味着加载当前状态非常快，并且您拥有完整的日志，您可以在其中返回。TimePeriod 的原因是，这通常是您实际考虑此类事情的边界。
理论与建筑
如果您深入研究会计理论和历史，您会发现“文件”应该是源文件——采购订单、发票、支票等。会计记录是那些通常人类可读的源文件的标准化摘要。会计交易是两个或更多记录，涉及两个或多个帐户，绑定在一起，借方和贷方平衡。账户余额、资产负债表或损益表等报告只是这些交易的摘要。
把它想象成一个分层的架构——底层，基础，是源文档。如果源是电子的，那么它会进入会计系统的文档存储层——这就是 nosql db 可能有用的地方。如果来源是一张纸，则将其成像和/或使用索引号归档，然后将其存储在会计系统的文档层中。下一层是总结这些文件的数字记录；每份文件都由一个或多个不平衡交易分支进行汇总。下一层是平衡交易；每笔交易都由两个或多个不平衡腿组成。顶层是总结这些平衡交易的财务报表。
源文档和外部应用程序
源文件是“唯一的事实来源”——而不是描述它们的记录。您应该始终能够从源文档重建整个数据库。在某种程度上，数据库首先只是源文档的索引。太多人忘记了这一点，并编写了将交易本身视为事实来源的会计软件。这导致需要一个完整的“另一个源文档本身的存储和工作流系统”，而您最终会遇到典型的现代企业混乱。
这一切都意味着任何写入会计系统的应用程序都应该只创建源文档，将它们添加到底层。但在实践中，这一直被绕过，应用程序直接创建事务。这意味着源文档，而不是在会计系统中，现在在创建交易的应用程序中；那是脆弱的。
事件、工作流程和数字化
如果您正在使用某种事件模型，那么使用事件的正确位置是将源文档附加到它。然后该事件触发该文档被解析为正确的会计记录。如果源文档已经是数字化的，则可以以编程方式进行解析，如果源是一张纸或未格式化的消息，则可以手动完成——听起来像是工作流系统的开始，对吧？不过，您仍然希望将原始源文档保留在某个地方。文档数据库似乎确实是一个好主意，特别是如果它支持一种模式，您可以将源文档与它们生成的已解析和平衡记录联系起来，反之亦然。
在这种情况下，关系数据库是最合适的，因为您有关系数据（例如行和列）
由于这只是一个个人系统，因此您不太可能遇到任何规模或性能问题。
话虽如此，对于个人成长和学习使用像 RavenDB 这样的基于文档的数据库来说，这将是一个有趣的练习。传统上，金融一直是一个非常正式的东西，关系数据库通常被认为比文档数据库更正式和严谨。但是，正如您所说，此应用程序的域在您的控制之下，并且相当简单，因此复杂性和要求不会妨碍设计系统。
如果这是我自己的个人宠物项目，我想了解更多关于新技术的信息，看看它是否适用于特定领域，我会选择我觉得有趣的任何东西，如果它不是很好用，那么我学到了一些东西。但是，您的里程可能会有所不同。:)