私たちは DDD を学習し、レガシー システムとデータストアに支えられたシステムでの使用を評価しています。
私たちは Anti-Corruption Layer、Bubble Context、Bounded Context を知らずに使用してきましたが、このアプローチは非常に実用的です。
しかし、識別方法と同一性相関については確信が持てません。従来のデータ ストアには主キーがなく、代わりに複合一意インデックスを使用して情報を識別します。
現在、エンティティである必要がある値オブジェクトとしてモデルを作成しています (すべてに「Long id」フィールドを追加したい)、または一意のインデックスで使用される属性の組み合わせを id フィールドとして使用することはめったにありません。エンティティ モデルに id フィールドが必要であることは明らかです。
ここに私の具体的な質問があります：
- 光沢のある新しいエンティティには、理論的には「Long id」フィールドが必要です。バックエンド データ ストアがそのフィールドに値を入力したり認識したりできないため、値が得られないため、そのフィールドを追加しなくても大丈夫ですか?
- DDD の方法で識別情報を保存し、後でそれをリファクタリングしても問題ありませんか?データストアがニーズに合わせて変更されることを願っています。
- もしそうなら、エンティティからの識別を抽象化することは良いアプローチですか（つまり、識別可能なインターフェース、またはエンティティごとのキークラスですか？-ここで良いアドバイスが必要です..）
- この質問は DDD の範囲外かもしれませんが、識別リファクタリングがシステムのいくつかのレイヤーに影響を与える可能性があるのではないかと思います (たとえば、REST API は/entity/id_field/id_field/id_fieldから/entity /new_long_id に変更される可能性があります) 。
と他の質問:
洗練されたドメイン モデルを成長させるためにレガシー情報をどのように使用すればよいでしょうか。
それとも、プロジェクトの存続期間中いつでも、ドメインのロング IDを希望するのは悪いことであり、価値がないのでしょうか?
アイデンティティ管理をどのようにリファクタリングできますか?
アップデート：
- ID 管理は DDD の重要な側面ですか、それともリファクタリング可能なインフラストラクチャーの側面なので、これ以上時間を費やすべきではありませんか?