Search code examples
classdomain-driven-designradix

Base Classes "Entity" and "ValueObject" in Domain-Driven Design


Do you always create these two abstract base classes as the basis of any new project in DDD?

I've read that Entity should have two things. First, an identity property, probably of a generic type. Second, an Equals() method that determines whether it's the same as another Entity. Anything else? Any other natural methods or rules of thumb?


Solution

  • I like to have a common abstract ancestor for all my Domain objects but that is a matter of preference and overall infrastructure requirements.

    After that, yes I have abstract classes for Entity and Value objects.

    Don't forget that also overriding Equals for Value objects to return equality based on equal property state can be important.

    Also people frequently overlook the value of packages. Put all these core base classes in their own "kernel" library and don't be reluctant to split your domain model into multiple assemblies instead of winding up with a single large "Domain Library".