私が基本的な個人会計システムを作成する場合 (私がそうなので、要件に行き詰まることを避けるために十分に精通しているドメインに関する趣味のプロジェクトです)、RavenDB のような NoSQL/ドキュメント データベースは次のようになります。アカウント、さらに重要なことに、それらのアカウントに対するトランザクションを保存するための良い候補はありますか? どのエンティティが「ドキュメント」であるかを選択するにはどうすればよいですか?
これは、実際には SQL データベースが適切であり、NoSQL に移行しようとするのは間違いであるというケースの 1 つであると思いますが、CQRS とイベント ソーシングについてほとんど知らないことを考えると、エンティティ/ドキュメントが実際にはAccountであり、トランザクションはそれに対して保存されるイベントであり、これらの「イベント」が発生すると、アプリケーションは SQL データベースのような簡単にクエリ可能な読み取りストアにも書き出す可能性があります。
よろしくお願いします。
個人的には良いアイデアだと思いますが、私のフルタイムの仕事は CQRS、イベント ソーシング、およびドキュメント データベースに基づく会計システムを構築することなので、少し偏っています。
理由は次のとおりです。
イベント ソーシングとアカウンティングは同じ原則に基づいています。何も削除せず、変更するだけです。間違ったトランザクションを追加しても、削除しません。オフセット トランザクションを作成します。イベントについても同じことが言えます。それらを削除するのではなく、最初のイベントをキャンセルするイベントを作成するだけです。これは、多数の TransactionAddedEvent を発行していることを意味します。
次に、複式簿記を行っている場合、取引を記録することは、画面 (特に貸借対照表) で表示する方法とは異なります。したがって、cqrsが再び好きです。正しい会計原則を使用してデータを保存できますが、読み取りモデルを最適化して、データを表示したい方法で表示できます。
貸借対照表で、特定の勘定科目のすべてのエントリを表示する必要があります。トランザクションには 2 つの側面があるため、トランザクションを表示する必要はありません。そのアカウントに影響するエントリのみを表示する必要があります。
したがって、ドキュメント データベースには、エントリ コレクションがあります。
これにより、クエリが非常に簡単になります。アカウントのすべてのエントリを表示する場合は、SELECT * FROM Entries WHERE AccountId = 1 とします。これが SQL であることは知っていますが、このクエリの単純さは誰もが理解しています。ドキュメントデータベースでも同じくらい簡単です。さらに、それは超高速になります。
次に、アカウント ID でグループ化されたクエリを使用して貸借対照表を作成し、日付に制限を設定できます。結合がまったく必要ないことに注意してください。これにより、ドキュメント データベースが優れた選択肢になります。
理論とアーキテクチャ
会計理論と歴史をしばらく掘り下げると、「ドキュメント」がソースドキュメント（発注書、請求書、小切手など）である必要があることがわかります。会計記録は、通常は人間が読める形式のソースドキュメントの標準化された要約です。会計トランザクションは、借方と貸方のバランスが取れた、2つ以上のアカウントにヒットする2つ以上のレコードです。口座残高、貸借対照表や損益計算書などのレポートなどは、これらの取引の要約にすぎません。
これを階層化アーキテクチャと考えてください。最下層である基盤がソースドキュメントです。ソースが電子的である場合、それは会計システムのドキュメントストレージレイヤーに入ります-これはnosqlデータベースが役立つかもしれない場所です。ソースが一枚の紙である場合は、それを画像化するか、インデックス番号を付けてファイルし、会計システムのドキュメントレイヤーに保存します。次の層は、それらのドキュメントを要約したデジタルレコードです。各ドキュメントは、1つ以上の不均衡なトランザクションレッグによって要約されます。次の層はバランスの取れたトランザクションです。各トランザクションは、これらの不均衡なレッグの2つ以上で構成されます。最上位層は、これらのバランスの取れたトランザクションを要約した財務諸表です。
ソースドキュメントと外部アプリケーション
ソースドキュメントは「信頼できる唯一の情報源」であり、それらを説明するレコードではありません。ソースドキュメントからデータベース全体をいつでも再構築できるはずです。ある意味で、dbはそもそもソースドキュメントへの単なるインデックスです。あまりにも多くの人がこれを忘れて、取引自体が真実の源であると考えられる会計ソフトウェアを書きます。これにより、ソースドキュメント自体のための別のストレージおよびワークフローシステム全体が必要になり、典型的な現代の企業の混乱に陥ります。
これはすべて、会計システムに書き込むアプリケーションは、ソースドキュメントのみを作成し、それらをその最下層に追加する必要があることを意味します。ただし、実際には、これは常にバイパスされ、アプリケーションが直接トランザクションを作成します。これは、会計システムではなく、ソースドキュメントが、トランザクションを作成したアプリケーションの向こう側にあることを意味します。それは壊れやすいです。
イベント、ワークフロー、およびデジタル化
If you're working with some sort of event model, then the right place to use an event is to attach a source document to it. The event then triggers that document getting parsed into the right accounting records. That parsing can be done programatically if the source document is already digital, or manually if the source is a piece of paper or an unformatted message -- sounds like the beginnings of a workflow system, right? You still want to keep that original source document around somewhere though. A document db does seem like a good idea for that, particularly if it supports a schema where you can tie the source documents to their resulting parsed and balanced records and vice versa.
そのようなシステムを確実に作成できます。そのシナリオでは、Account Aggregate があり、TimePeriod Aggregate もあります。期間は通常、月、四半期、または年です。各 TimePeriod 内には、その期間のトランザクションがあります。つまり、現在の状態の読み込みが非常に高速であり、前に戻ることができる完全なログがあることを意味します。TimePeriod の理由は、これが通常、実際にそのようなことを考える境界であるためです。
この場合、リレーショナル データ (行と列など) があるため、リレーショナル データベースが最適です。
これは単なる個人用システムであるため、規模やパフォーマンスの問題が発生する可能性はほとんどありません。
そうは言っても、RavenDB のようなドキュメント ベースの DB を使用することは、個人の成長と学習にとって興味深い演習になるでしょう。伝統的に、金融は常に非常に形式的なものであり、リレーショナル データベースは通常、文書データベースよりも形式的で厳密であると考えられています。しかし、あなたが言ったように、このアプリケーションのドメインはあなたの管理下にあり、かなり単純であるため、複雑さと要件がシステムの設計の邪魔になることはありません。
もしそれが私自身の個人的なペットプロジェクトで、新しい技術についてもっと学び、それが特定の分野で機能するかどうかを確認したかった場合、私は自分が面白いと思ったものを何でも使い、うまく機能しなかった場合は、私は何かを学びました。ただし、走行距離は異なる場合があります。:)