DDD Entity's Id modeling with existing database

Viewed 380

As stated by literature in Domain Driven Design each Entity is identified by an Id, usually of type long/int or GUID. In particular I followed the course by Vladimir Khorikov Domain Driven Design in practice. How do I deal with this when I'm designing on an existing database?

I have to deal with tables from my company's ERP, so I can't touch them or modify or ignore them, I have to model my entities above this persistence layer. Almost all tables does not have an integer identifier, but sets of fields of various types. How can I link my "clean" concept of an Entity with an Id with its persistence in a database without an integer Id?

1 Answers

You are considering the Entity to be a database table. That is not necesserily true in DDD as it is not true in code Repositories.

The entities that you expose from your Domain should just follow the following definition:

An object that is not defined by its attributes, but rather by a thread of continuity and its identity.

As far as the other interconnected domains are concerned you have an entity called for example Order.

In your data Order domain the order could be the sum of multiple database tables (i.e. the order is defined by a customer, a product and a shop). To create a unique id for this you can use multiple tricks.

  1. Indeed use the id of the topmost table (not applicable in your case)
  2. Get the composite key values and create a hashset. Maintain a local db table with the triplets and the hashsets and use this mapping on retrieval to access the underlying ERP database with none the wiser.
  3. Encrypt a the composite key value in a string "value1;value2;value3" and send the encrypted value as the id. On retrieval, decrypt and access the underlying ERP database

Remember: Domains are not about internal implementation, they are about communication and responsibilities.

Related