First, I'd like to clarify that DDD is all about domain modeling and has nothing to do with how the domain is persisted. It might be persisted in a a database, but it might just as well be in a text file. From a domain modeling stand point it matters which (and how) entities are related with other entities, but generally not how they are related in a relational database. To wit, ask a sales rep. how an order line item can identify the order its part of and he'll ask you in return what's wrong with you.
Performance wise there are some risks involved in using GUIDs as keys. Randomly generated GUIDs are not suitable for clustered indices. It is best to use a sequential generational algorithm and have the database provide you with those GUIDs. Here is a link to a discussion on this topic:
What are the performance improvement of Sequential Guid over standard Guid?
I would advise you to read this answer in particular. I agree with Dan that having sequential GUIDs is missing the point.
Relationally speaking, it seems unnecessary and generally unwise to me to have two identifiers for the same record. I would advise you to pick one. So, if somehow you are stuck with GUIDs in your project. See if you can use them as keys by having them sequentially generated. Then you can remove your @Id Long id
. If not, replace the @EmbeddedId
with a @Column
annotation.
Hope this helps,
Good luck