A brief exploration to help you save instant time

Feather infraspeak, the entire engineering team gets a few days every month to fully dedicate to pet projects. As my friend, Nelson, and I worked on our automation bot, we introduced the first entities to our domain without noticing that we were creating invalid instances. This article shows why those examples were broken from the start and how to make sure we always work with valid examples before they are persisted to the data store.

Entities are defined by threads of continuity and identity. This means that by having a unique ID, it will still be the same entity whenever the values ​​of their properties change, and we will always be able to reference it (this is the persistence part).

When developing software, it is widely accepted that we should strive for immutable objects. If we want to change something inside immutable objects, we create new instances with updated values. This prevents an object from being mutated inadvertently during the execution of application logic, possibly putting it in an invalid state.

I won’t delve too much into this pattern (rain check for another post), but the point is that when working with immutable objects, they must be in a valid and usable state. Anywhere that accepts that object doesn’t have to worry about constantly checking its validity.

Therefore, if an identity by means of a unique ID completely defines an entity, and must be considered valid immediately upon instantiation, then sequentially generated numbers from the data store can be used as the source of the entity identity. Doing it is a problem. And here’s why: We can’t safely predict what the next number is, and it’s not even the entity’s responsibility to do so, leaving us in a dilemma: We need to continue with it and find that ID. An entity needs to be instantiated in order to get it, but we can’t because we must have an ID to instantiate it. so what to do?

A simple, intuitive solution would be to accept two types for the ID property: an integer or a null, This fixes the problem of instantiating the object but doesn’t make it valid. We have now created an indirect dependency on the data store as we need to first persist the entity and create a new instance with the real id. This needs to be done before we can use it further in the application.

The thing is, although broken, this is the most common implementation I’ve seen when working with entities. I have done it this way too. Nevertheless, I recently found another way to work with perfectly valid entities, without requiring them to persist in the data store before being used in the application.

The trick is to abandon the use of sequential IDs generated internally from the data store at the application level and replace them with random, uniquely-identifiable IDs such as UUIDs. Using UUIDs, we can generate unique IDs and have perfectly valid entity instances to work with immediately. It would also remove a difficult dependency on the data store.

We can save on object instantiation time as we no longer need to recreate an entity class on persistence as there is probably no new property to fetch. Whereas before, we will need to do this to populate the ID from the data store. The persistence of the entity becomes an implementation detail.