As we have seen, having objects primarily defined by their properties can be really useful and helps us deal with a lot of scenarios when designing a system. So, we often see that certain objects have a different lifecycle attached to them. In such a case, the object is defined by its ID, and in domain-driven design terms, it is considered an entity. This is a contrast to value objects that are defined by their properties, and are considered to be equal when their properties match. An entity is only ever equal if it has the same ID, even if all the properties match; as long as the ID is different, the entity is not the same.

Entity objects manage the lifecycle inside the application; this can either be the lifecycle spread across the application as a whole, but it might well be a transaction happening in the system. In the dungeon, we are dealing with a lot OF cases where we don't really care about the lifecycle of an object itself, but rather WE care about its...