DDDを使用するシステム（およびORMを使用するすべてのシステム）を検討してください。ほぼすべてのユースケースで、現実的にシステムのポイントは、これらのドメインオブジェクトを操作することです。それ以外の場合、実際の効果や目的はありません。
不変オブジェクトを変更すると、オブジェクトが永続化された後に新しいレコードが生成され、データソースに大量の膨張が発生します（変更後に以前のレコードを削除しない限り）。
不変オブジェクトを使用することの利点はわかりますが、この意味では、不変オブジェクトを使用する便利なケースはありません。これは間違っていますか？
回答:
（関数型プログラミングのように）不変オブジェクトを使用した計算は、生成されるすべてのオブジェクトを永続化することを必ずしも意味しません！
ドメインで不変とは、データベースで不変でなければならないということですか？たとえば、顧客が常に1つの住所を持っていると仮定して、次のことを検討してください。
customer.address = new Address('My Castle', 'Kings street');
customer_repo.save(customer);
顧客IDが1であることを考慮して、次のSQLが実行されます。
INSERT INTO addresses (customer_id, name, street)
VALUES (1, 'My Castle', 'Kings street');
現在、アドレスに対して次の変更が行われています。
customer.address = new Address('Pauper palace', 'Outlands');
customer_repo.save(customer);
そして永続化レイヤーは、非常に賢いので、次のSQLを実行します：
UPDATE addresses SET name='Pauper palance', street='Outlands'
WHERE customer_id = 1;
これにより、個別のDELETE AND INSERTステートメントのオーバーヘッドを回避できます。また、一部のRDBMSにはINSERT REPLACEなどがあると思います。MySqlにはREPLACEがあります。
これは、データベース内で不変オブジェクトがどのようにマップされるかによって異なります。（Joda Timeライブラリからの）DateTimeのような単なるコンポーネントの場合、値を変更すると、挿入ではなく更新が行われます。ただし、不変オブジェクトがより複雑で、テーブルに行が必要な場合は、肥大化の問題が発生します。
弱い議論ですが、この方法で監査証跡を実装できると思います。immmutableに対するすべての変更は、挿入を通じて追跡できます。しかし、これを行うためのより良い方法がたくさんあります。
全体的に（単にコンポーネントではなく）不変のドメインオブジェクトを持っているのは、永続性とは少し不一致のようです。
それはドメインに依存します。DDDは、プログラミングパラダイムがオブジェクト指向であることを指定していません。ただし、オブジェクト指向のパラダイムは、データベースに永続化する必要がある一般的なアプリケーションに適しています。
DDDは、ソフトウェアが解決しようとしている実際の問題を表すドメインモデルを中心にソフトウェアを構築する必要があると単に述べています。その問題が本質的に数学的なものである場合、関数型プログラミングと不変のデータ構造を使用してドメイン層を実装することは非常に理にかなっています。
一方、問題がより典型的なエンタープライズアプリケーションであり、すべてのドメインオブジェクトに不変オブジェクト構造を使用している場合は、DDDに従っていないと主張します。少なくとも2つの引数を考え出すことができます。
実装は、問題のあるドメインのドメインモデルを表していません。この場合の問題ドメインは、変更する状態を持つエンティティで構成されます。そして、それはあなたがそれを実装した方法ではありません。
ユビキタス言語はありません。ドメインモデルの言語と概念は、ドメインの専門家が使用しているものに従いません。
注：DDDは、必要に応じて不変オブジェクトを使用します。これらは単に値オブジェクトと呼ばれます。
したがって、純粋に機能的なデータ構造を使用してデータベースアプリケーションを作成できないと言っているのではありません。アプリケーションの種類によっては、DDDと呼べるとは思わない
値オブジェクトはほとんど常にDDDで不変であり、フライウェイトパターンを使用して、.NETが文字列で行うようにメモリ内でその値オブジェクトの複製を保持できます。主なトレードオフは、メモリの片側と反対側の作成効率です。flyweightパターンでは、値ベースの比較を実行して、新しい値オブジェクトまたは再構成された値オブジェクトが既にflyweightキャッシュ内にあるかどうかを判断する必要がありますが、その時点以降のその他の比較は、単一のインスタンスが適用されるため、一般に参照によって安全に実行できます。flyweightが使用されるかどうかに関係なく、値オブジェクトは固有のIDのみを持ち、したがって値を変更するとIDが変更されるため、不変になります。