Home/ Questions/Q 7856785
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T20:49:03+00:00

We are learning DDD and evaluating its use for a system backed by a

  • 0

We are learning DDD and evaluating its use for a system backed by a legacy system & datastore.

We have been using Anti-Corruption Layer, Bubble Context and Bounded Context without knowing about them, and this approach seems very practical to us.

But we are not certain and confident about identification methods and identity correlation.
Legacy data store does not have primary keys, instead uses composite unique indexes to identify information.

We are currently creating our model as Value objects that should be Entities (wishing to add “Long id” field to every one), or we rarely use combination of attributes used in unique indexes as id field. It seems clear to us that Entity models should have id fields.

Here are my concrete questions:

  • We want our shiny new Entities to have “Long id” fields theoretically. Is it OK not to add that field now since that gives us no value as the backend data store won’t fill or understand that field?
  • Is it OK in DDD way to store identification information and refactoring it sometime later hopefully datastore changes towards our needs.
    • If so, is abstracting identification from Entities good approach (I mean Identifiable interface, or KeyClass per Entity? – Any good advice is needed here..)
  • This question may be out of the scope of DDD but i wonder if identification refactoring can cause impacts on several layers of the systems (For example, REST api may change from /entity/id_field/id_field/id_field to /entity/new_long_id)

and other questions :

  • How can we use the legacy information for our growing polished domain model, with less pain in identification stuff?

  • Or is it bad and not valuable to wish Long id for our domain at anytime of the project’s life?

  • How can we refactor identity management?

Update:

  • Is identity mgmt important aspect of DDD or is it an infrastructural aspect that can be refactored, so we should not spend more time in it?
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Use whatever identifier fits your needs, but be realistic and upfront about the cost and implications of choosing the wrong one. There is merit in assigning identifiers from the outside and just storing them along the other bits of information (regardless of format (guid, long, uuid)). Whether or not to refactor identity mgmt is more about doing a cost/benefit analysis. Is it even an option with the legacy system, and in what kind of timeframe will there be two keys sidebyside? Why are you even reusing the same datastore? Why not partition it so you can have parallel data stores (worst case even syncing data between both of them, preferably in one direction)? Try some vertical slicing instead of horizontal. HTH.

    • 0