レガシー アプリケーションのアーキテクチャを確認したところ、3 層パターンが使用されていることがわかりました。問題は、ドメイン クラスまたはビジネス クラスがデータ レイヤー クラスから継承されていることです。私は常にビジネス クラス内のデータ レイヤー オブジェクトを参照して呼び出します。
アーキテクチャをそのように実装する目的がわかりません。関心の分離を壊していると思いますが、何かが欠けているかどうかはわかりません。
似たようなものに出会ったことがありますか？この継承を行う理由、または行わない理由について正当な理由はありますか?
問題は、ドメインまたはビジネスクラスがデータレイヤークラスから継承することです...この継承を行う理由または理由の正当な理由はありますか?
ビジネスレイヤーとデータレイヤーを明確に分離したい場合（優れた柔軟なシステムならそうなるでしょう）、このアプローチは間違いなく私の匂いがします。
このタイプの継承を正当化できる唯一の理由は、バックエンドが変更されず、DAL が常にドメインと同じ定義を使用するという保証が必要だということです。一般に、DDD ではユビキタス言語の側面はドメインに制限されており、DAL では実際に問題になることはありません。
要約すると、柔軟性に関しては優れたアプローチではないと思います。ただし、そのシステムのコンテキストに依存するため、設計が悪いかどうかはわかりません。