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?
iesen
  • 65
  • 2
  • 11

1 Answers1

0

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.

Yves Reynhout
  • 2,982
  • 17
  • 23
  • Datastore is far from normalized schema. Composite keys with 7-8 columns are copied everywhere. If we can replace legacy applications using same data, than we can refactor database. But while replacing legacy apps we want to use our desired model. – iesen Apr 29 '12 at 12:54
  • We can't foresee the implications of syncing method, since we dont have full knowledge about the domain just now, we can use it in future but identity issues are taking away our focus from core domain..Maybe another question: is identity mgmt important aspect of DDD or is it an infrastructural aspect that can be refactored? – iesen Apr 29 '12 at 13:05
  • Desired model as in data model? Are the current keys immutable (I hope so)? Could you do a mapping (look up new long id based on 7/8 column values) and use that in the new data store? – Yves Reynhout Apr 29 '12 at 13:23
  • Don't get too hung up on the identity of things. Providing a surrogate identity should be simple. Why even keep the old identity columns around? – Yves Reynhout Apr 29 '12 at 13:27
  • For desired model, i mean Entities, Value objects and Aggregates that are constructed in DDD way (first step of DDD). Current composite keys are not always immutable unfortunately. We can map new long id and composite ones in the same datastore or another, but once legacy applications do manipulations we have to keep those tables in sync with triggers or somethings else. We already used some triggers in this way in fact...Old identity columns cannot be refactored since legacy apps are tightly coupled on them. Mapping identity columns may be appropriate solution.. – iesen Apr 29 '12 at 13:43
  • Again, try to replace an entire vertical slice. – Yves Reynhout Apr 29 '12 at 20:12
  • well we decided to put Key objects for our Entity models, and make the repository manage the Key abstraction upon fetching and updating aggregates.. – iesen May 03 '12 at 17:45