アカウントのトランザクションとバランスの抽象化
クレジット/デビットライントランザクションをログに記録せずに、アカウント残高テーブルを更新するアプリケーションが10個あります（理由は不明）。それらはすべて同じSQLステートメントを持っています。この構造から抜け出し、トランザクションをログに記録するために、以下を提案します。最後の方法を見直して、設計をより最適化または抽象化するために推奨される他の方法はありますか？
現在の構造：
10アプリケーション--->埋め込みSQL --->データベースのバランスを更新
より良い構造：
10個のアプリケーション--->リポジトリC＃Linq --->データベースのバランスを更新
最も抽象的な構造：
10個のアプリケーション--->サービスレイヤー->（TransactionLineリポジトリ---->アカウント残高リポジトリを含む）--->トランザクションとアカウント残高テーブルを更新します
ドメインの概要
domain のアカウンティングには、次の異なるが関連する概念があります。
- accountは、説明される基本的な金融「トピック」を識別します。
- atransactionまたはa postは、アカウントへの値のいくつかの変更を集約するビジネスイベントを表します。
- a（投稿/トランザクション）lineまたはitemは、正確に1つのアカウントに影響する値の変更を文書化するトランザクションの一部です。
- 口座残高は、関連するすべての項目を考慮して、口座の価値を要約します。
- aledgerは、時系列順に並べられた一連のトランザクションです。 総勘定元帳は、アカウントごとに時系列順に並べられたすべてのアイテムのセットです。
基本的な（ここでは多少単純化された）概念のほかに、すべての場合に保証するいくつかのビジネスロジックがあります。
- トランザクションのすべての借方と貸方の合計は等しくなければなりません（または、負の数の貸方を表す場合、合計は0でなければなりません）。
- 結果として、元帳または総勘定元帳のすべての借方の合計は、機械的にも等しくなります。
- 総勘定元帳のアカウントのアイテムの合計は、常にそのアカウントの残高と等しくなければなりません
代替設計の分析
現在のアプローチは、各アプリケーションの品質に非常に敏感です。各アプリケーションはルールを破り、他のすべてのアカウントを混乱させる可能性があります。
Linqのアプローチにより、すべてのアプリケーション間の一貫性が向上します。しかし、特に1つのアプリケーションを更新し、他のアプリケーションを再コンパイル/デプロイするのを忘れた場合は、すべての新しいドメインオブジェクトの一貫した更新を保証できると確信していますか？
より抽象的なアプローチは、よりきれいなアーキテクチャを持っているようです。さらに、サウンドを実装します 懸念の分離 ：
- 10個のアプリケーションはそれぞれ、独自の専用アプリケーションロジック（販売、購入、在庫管理など）を実装します。
- アカウンティングの共通ドメインロジックは、アカウンティング サービスレイヤー によって保証されます。サービス層を徹底的にテストすると、アプリケーションがアカウントをめちゃくちゃにできないことを確認できます（誰かが再コンパイルを忘れた古いバージョンのアプリケーションである場合）。各アプリケーションでは、開発者は適切なトランザクションが記録されることを心配するだけでよく、会計の詳細を理解しなくても、アプリケーションの専用ロジックのみにテストを集中できます。
- 会計ロジックを改善し、たとえばいくつかのログ機能を追加する場合（たとえば、財務監査人の要求に応じて）、サービスレベルでそれを行うだけで済み、すべてのアプリケーションが機能することを確認できます。新機能で期待どおり。
したがって、最終的にアプリケーションはアカウンティング計算を実行する必要がなくなります。アプリケーションは、使用するアカウントを取得するためにサービスにクエリを実行し、サービスに一貫したトランザクションを送信します（ある種の [〜＃〜] dtoを使用して） [〜＃〜] ）、および必要に応じて勘定残高を照会します。