C# Domain-Driven Design – Is It Normal for a Domain Model to Lack an ID?

cdomain-driven-designentity

After reading the book; I understood the following:

1) Entities should implement equality and compare by ID.
2) Value Objects should implement equality and compare by all properties in the class.

I still believe that my understanding of point two is correct. However, I am confused about point one because of the following:

1) This blogger talks about creating an entity base class, which all entities inherit from: http://enterprisecraftsmanship.com/2014/11/08/domain-object-base-class/. Therefore all entities implement equality by ID because the equality comparisons are defined in the base class.

2) Most of the entity classes here have IDs: https://github.com/nhibernate/nhibernate-core/tree/master/src/NHibernate.DomainModel/Northwind/Entities

3) This question seems to suggest having an ID attribute: ID properties on Domain objects in DDD

4) This question points to a YouTube video (point one) where it is argued that entities should not have IDs.

Points 1-4 above seem to suggest either: 1) use a database ID; 2) use another ID that is not the database ID; 3) Use no ID.

I am trying to decide whether:

1) Have an entity superclass.

or
2) Have an ID (from database) in every entity.

or
3) Introduce an identifier (not database id) that identifies domain objects.

I am trying to completely isolate the domain model (I also have a data model).

Best Answer

By definition, entities have an identity.

This fact, by itself, does not imply that you must have an Id property on your entity objects. If you never need to reference or compare the entity outside of your aggregate, there is not really a need for it.

Usually however, it makes sense for every entity to have an Id. Where does the Id come from? Unless you have a specific reason to do otherwise, I would prefer to have the application create the Id, not the database. You can use UUIDs (Guid in C#) or some custom IdGenerator. The fact that the database may use the Id value as a key is purely coincidental as far as your domain model is concerned.

This leaves the question of the Entity base class. There are a few reasons why you might not want to have one:

Entity is not a domain concept, so having your domain objects depend on it is not ideal.

You might argue that Id is not a domain concept, either. Practical reasons for introducing it aside, I would argue that identity is an implicit domain concern - otherwise you could just use value objects.
The Entity will have very little functionality. Inheriting from it just to have an Id property, and possibly a very stable one-line (this.Id == other.Id) equality check seems like overkill.

That being said, I think it's very unlikely you'll run into problems due to the Entity base class. So if it helps you to focus on the domain logic (e.g. by not allowing you to forget to override Equals, in case this is how you intend to implement the equality check), by all means go for it.

Related Solutions

C# – .NET software design and Oracle ODP.NET UDT

nHibernate, Entity Framework and other ORM (Object Relational Mapping) tools are wonderful to represent abstractions of the database objects (Tables/Views), relationships and keys through true business objects in the data layer of an application. The motive around the ORM tools are to make the data layer robust and to support Rapid Application Development (RAD) through different design time support in Visual Studio to map and represent database objects and relationships in the data layer. ODP .Net UDT to some extent support all these philosophies. However, if you would like to truley provide complete object relational abstraction in data layer, either nHibernate or Entity Framework should be used.

Class Naming Conundrum in C#

When naming classes it's often tempting to include words that describe usage in programming terms. These words might include abstract, entity, and/or base. So you end up creating classes like AbstractOffice or BaseOffice. The name of the class implies two meanings what it does Office and how it's used Abstract. I don't recommend doing this. It adds extra details in the name that it doesn't need.

KISS (Keep It Simple Stupid)

I recently refactored a project I did a year ago to use simple names, and it became much easier to read the code. Give it a try and see if it helps. You can always rename the classes later.

public class Employee : Data
{
    public int Id { get; set; }
    public string LastName { get; set; }
    public string FirstName { get; set; }
}

[Sql(@"SELECT [EmployeeId], [LastName], [FirstName] 
   FROM [Employees] 
   ORDER BY [LastName], [FirstName]")
public class Employees : Query
{
    public int Id { get; set; }
}

When you remove programming specific terms (i.e. I removed Select, Entity and renamed Sql to Query). The classes become more readable. Now their names infer only specific information (i.e. this is about an employee). The implementation that it uses SQL or represents an entity pattern is irrelevant. That information should go into the class comments not it's name.

In the future, you will have a bug. Which description is easier to understand, and a result easier to find in the source code.

Employee John Smith is not an active member of Employees.

EmployeeEntry John is not an active member of SelectEmployee

That's just an example, but later when you're using those classes the code becomes difficult to read. A sea of terms that aren't relevant to what the code is doing.

Best Answer

Related Solutions

C# – .NET software design and Oracle ODP.NET UDT

Class Naming Conundrum in C#

Related Topic