データベースエンティティをソフトウェアアーキテクチャの別のレイヤーにコピーしますか？
SqlServerデータベースでEntity Frameworkを使用しています。ストレージ、高いクエリコストなどのため、ビジネスプログラムはデータベースにない多くの列を作成する必要があります。現在、チームはDBエンティティレイヤー全体を（足場から）コピーし、新しいエンティティに計算されたメンバーを追加して別のレイヤー全体を作成しています。現在、EFレイヤーを取得し、AutoMapperを新しいレイヤーに適用しています。何らかの理由で、これが最適かどうかはわかりませんが、建築家はこの方法を望んでいます。
ソフトウェア業界では、データベースレイヤーを計算されたメンバーを含む別のコピーレイヤーにコピーするのが一般的ですか？ DDDドメイン駆動設計を知っていますが、集約ルート、値オブジェクト、クラスターなどは作成していません。
これが適切でない場合の代替ソリューションは何ですか？
*私は2年前に大学からソフトウェアプログラミングを始めましたが、これが業界の優れた慣習なのか、それとも代替手段があるのか知りたいです。グーグルとスタック全体を検索し、この戦略を引用しなかった。
だから基本的に
SQLデータベース---> EFレイヤー--->別のコピーレイヤー（クラス内のEFおよびコンピューターメンバーと共に）--->アプリケーションサービス---> Dto --->コントローラーAPI
計算されたメンバーを持つこのEFコピーレイヤーを除いて、すべてのレイヤーに同意します。部分クラスだけを利用できませんか？
例：新しいクラスレイヤーには、既存のすべてのメンバーに加えて、クラスに追加されたメンバーなどが含まれます。
FullName => FirstName + LastName
AccountValue => Quantity * StockPrice
更新：
別の考え方をしている人からも聞きたいと思います。以下の回答に感謝します。
ソフトウェア業界では、データベースレイヤーを計算されたメンバーを含む別のコピーレイヤーにコピーするのが一般的ですか？
例：新しいクラスレイヤーには、既存のすべてのメンバーに加えて、クラスに追加されたメンバーなどが含まれます。
FullName => FirstName + LastNameAccountValue => Quantity * StockPrice
ここで使用しているのはエンティティ間の区別（=データベースレコード）およびドメインオブジェクト（=「より完全な」データオブジェクト）です。これはDDDに固有のものではありません。 DDDは他のアプローチよりも強くそれを強調しますが、それは非DDDシナリオでも完全に実行可能なアプローチです。
計算値はどこに置きますか？それらをデータベースに保存しないでください（不要なデータサイズの膨張）。また、これらの計算された値にドメインのすべてのコンシューマーが簡単にアクセスできるようにする必要があります。論理的には、ドメインはこれをdbレコードにラップする必要があります。これは、参照している「コピー層」です。
これを「コピー層」と呼ぶと、抽象化層の目的が見えないことがわかります。
このレイヤーはコピーではなく、独自の機能目的を持つ1つのレイヤーです（その1つはドメインからデータベースエンティティを抽象化することです）。 （とりわけ）同様のデータを公開するため、データベースエンティティに部分的に似ているだけです。
それはあなたの解釈がどこから来ているのかわからないということではありません。多くの場合、別のレイヤーを効果的に複製するものを書く必要はありません。この追加の抽象化は現在必要ないかもしれませんが（データベースレイヤーに完全に類似している場合）、後から後から追加する必要がある場合よりも、最初から実装する方がはるかに簡単ですdoesが必要になります。
その意味で、この抽象化レイヤーを今日実装することは、明日より厄介なタスクを回避するために必要です。
はい、これは一般的な方法です。
EFはオブジェクトを作成するため、EFは奇妙に見えます。 DataReadersなどでSqlClientを直接使用しているだけなら、二度と考えることはないでしょう。
問題は、EFオブジェクトが属性を介してEFに密接に結合されていることが多いことです。これは、EFを参照する必要があるオブジェクトをどこで使用するかを意味します。使用していないときに本当にしたくないこと。
理論的には、最初にEFオブジェクトをコーディングしてビジネスレイヤーオブジェクトを直接使用できますが、実際には、リポジトリパターンを介してEFオブジェクトをビジネスレイヤーにマップする方が簡単な場合があります