オニオンアーキテクチャ、パーシスタンスと通知

Question

私は勉強中オニオンアーキテクチャと私はポイントがあります。

オニオンアーキテクチャは、技術的な成果物からドメインを分離することを目指しています。したがって、データアクセスレイヤ（DAL）がドメインレイヤ（BL）を参照できるようにすることがガイドラインです。このようにして、エンティティをストレージアーチファクトに変換できるはずです。 BLを参照すると、おそらく私のドメインの「スナップショット」が得られるはずですが、変更追跡システムがなければ、データストア内のアイテムを挿入、更新、削除するかどうかをすべての年代順のイベントで解消し、その後のモデル。

オニオンアーキテクチャでは、常に変更追跡システムやイベントストアなどが必要ですか？他のパターンがありませんか？

Answer 1

ドメイン層は、永続化が必要なときを知っていますか？

たとえば、新しい顧客を更新すると、新しい顧客を保存する画面が表示されることがあります。その時点で私は変更の追跡について気にしない、私はちょうど私が持っているすべてを保存したい。私のDALは、既にデータベースに同じ名前の顧客があるかどうかを知ることができます（挿入または更新クエリを発行する必要がある場合）。

イベントストアにも同じことが適用されます。あなたのドメインがイベントを気にしていて、イベントを元に戻すことができる技術的な実装ならば、イベントストア。

あなたのドメイン層は常に完全なメモリ上のライブ突然変異システムで構成されます。その場合、スナップショットさえありません。

タマネギのアーキテクチャは、アーティファクトの分離を説明しています。どのアーティファクトが実際に特定の要件に依存するか。

Answer 2

アプリケーション層がそれを担当することになっています。アプリケーションサービスは、ドメインへの呼び出しをオーケストレーションすることによってユースケースを実装します。ユースケースの一部として作成または変更されたドメインエンティティは、後の永続性のために1つの形式または別の形式でメモリに保持する必要があります。

一般的なやり方は、それらを実装単位がインフラストラクチャ層にある作業ユニットに配置することです。ドメインエンティティに対する変更を追跡します。アプリケーションサービスがビジネストランザクションを終了すると、作業ユニットはエンティティ状態を永続ストアにフラッシュ可能なものに変換します。