Some concepts in the Domain demand Identity — that is, changes to their internal states don't change their own unique identities. We've seen how modeling Identity as a Value Object brings benefits like immutability, in addition to logic for operating the Identity itself. We've also shown several ways of providing Identity, restated in the following pointers:

• Persistence mechanism: Easy to implement, but you won't have the Identity before persisting the object, which delays and complicates event propagation.
• Surrogate ID: Some ORMs require an extra field on your Entity to map the Identity with the persisting mechanism.
• Provided by the client: Sometimes the Identity fits a Domain concept and you can model it inside your Domain.
• Generated by the application: You can use a library to generate IDs.
• Generated by a Bounded Context: Probably the most complex strategy. Other Bounded Contexts provide an interface for generating Identities.

We've seen and discussed Doctrine as a persistence mechanism, we've looked at the drawbacks of using the Active Record pattern, and finally, we've checked different levels of Entity validation:

• Attribute validation: Check for specifics inside the object state through preconditions, postconditions, and invariants.
• Entire object validation: Look for consistency of an object as a whole. Extracting the validation to an external service is a good practice.
• Object compositions: Complex object compositions could be validated through Domain Services. A good way of communicating this to the rest of the application is through Domain Events.