問題タブ [ddd-service]

私が開発している会計システムの DDD アプローチに従っています。

2 つの部分があります (以下のドメインを参照)。

1. トランザクションの作成: トランザクション (AccountingTransaction) は、現金が元帳からクライアントのアカウントに、またはその逆に、またはある元帳から別の元帳に移動されるときに、親 (集約ルート) として作成されます。つまり、Transaction(AccountingTransaction) は複数の LedgerTransaction または CashTransaction を持つことができます。
2. アカウントの照合 : 各元帳の貸方と借方を毎日照合する必要があります。

これは私のドメインがどのように見えるかです:

1. AccountingTransaction は集約ルートです。
2. LedgerTransaction と CashTransaction は、AccountingTransaction の子エンティティです。
3. AccountingTransaction には、CashTransactions と LedgerTransactions のリストがあります。
4. Ledger は集約ルートです。

したがって、最初の部分 (トランザクションの作成) は非常にうまく機能し、元帳勘定の調整にどのようにアプローチするべきかについて悩んでいます。

問題:アカウントを調整するには、特定の日に、ReconciledOn (ドメイン クラスを参照) が null である特定の Ledger に属するすべての Ledger トランザクションを取得する必要があります。次に、すべての借方と貸方の合計が 0 であることを確認する必要があります。そうでない場合は、エラーを報告する必要があります。一致する借方と貸方が異なる集約ルート (AccountingTransaction) に属することも可能です。これは、集約ルート (AccountingTransaction) の外で Ledger トランザクションを取得する必要があることも意味します。これは DDD に反しており、おそらく LedgerTransactions テーブルに対して直接書き込み操作を実行します。

これにどのようにアプローチすればよいかアドバイスしてください。ドメインクラスに欠陥はありますか?

私はあなたの助けに感謝します。

ありがとうございました！

次のシナリオがあります。

ショップになって所有者アカウントを取得するには、事前にリクエストを作成する必要があります。

ある日、リクエストを登録します。マネージャーがリクエストを確認して承認してから 2 日後、システムがショップとオーナーのアカウントを作成する必要があることを意味します。

私のモデルでは、リクエスト、ショップ、オーナー アカウントが 3 つの集計ルートであると考えていましたが、1 つのトランザクションで複数の集計を更新できないことを読みました。外部認証サービス) を別々の db サーバーに配置します。

問題は..まだリクエストがあり、承認されたら、2 つの集約ルート、ショップを作成する必要があります (すべてのショップ属性を使用して、連絡先の電子メールや電話の制限など、データにいくつかの不変条件しかありません)。 ) と所有者アカウント。

次に、1 つの所有者アカウントが他の誰かのショップを編集できるようにします (コラボレーターなど)。

どうすればそれをモデル化できますか?

ありがとう！

私は DDD を実践しようとしていますが、以下に書いたこのタイプのルールには疑問があります。

ドメイン層の下のクラス UserAggregator。

ドメイン層の下のリポジトリ インターフェイス。

UserRepository/ArchiveUserRepository は、Spring データを使用してインフラストラクチャ レイヤーの下に実装されます。

インフラ層の下のサービス。

私の管理ルールは、userNameがパターンと一致しない場合、ユーザーをアーカイブテーブルにアーカイブし、ユーザーテーブルから削除すると述べています。

お気づきのように、ルール (//1 から //3 まで) はサービス クラスに記述されており、アグリゲーターには記述されていません!

これは正しいです ？またはこれを管理する方法は？