We continue our series in the chapter 5 about Entities 😁
A. The problem
Here is the problem, our entities do not reflect the importance of
Instead of designing domain concepts with rich behaviors, we might think primarily about the attributes (columns) and associations (foreign keys) of the data. Doing so reflects the data model into object counterparts, which leads to almost every concept in our “domain model” being coded as an Entity abounding with getter and setter methods.
here is the problem, we have entities we only getters and setters and no domain logic!
B. What is a true Entity
We design a domain concept as an Entity when we care about its individuality, when distinguishing it from all other objects in a system is a mandatory constraint. An Entity is a unique thing and is capable of being changed continuously over a long period of time. Changes may be so extensive that the object might seem much different from what it once was. Yet, it is the same object by identity.
It is the unique identity and mutability characteristics that set Entities apart from Value Objects
C. When a CRUD is enough 🙃
There are times when an Entity is not the appropriate modeling tool to
reach for. Misappropriated use happens far more often than many are aware. Often a concept should be modeled as a Value. If this is a disagreeable notion, it might be that DDD doesn’t fit your business needs. It is quite possible that a CRUD-based system would be more fitting. When CRUD makes sense, languages and frameworks such as Groovy and Grails, Ruby on Rails, and the like make the most sense. If the choice is correct, it should save time and money.
D. When DDD is necessary😉
When complexity grows, we experience the limitation of poor tool selection. CRUD systems can’t produce a refined business model by only capturing data. If DDD is a justifiable investment in the business’s bottom line, we use Entities as intended.
And if we talk about the fact to track changes of an entity, that entity has to have a unique identifier , and Eric Evans says :
When an object is distinguished by its identity, rather than its attributes, make this primary to its definition in the model. Keep the class definition simple and focused on life cycle continuity and identity. Define a means of distinguishing each object regardless of its form or history. The model must define what it means to be the same thing
E. Unique Identity for an Entity
So that’s what we’ll do first. Having a range of available options for implementing identity is really important, as are those for ensuring that the uniqueness is preserved throughout time.
We will go through each of the method for ensuring unique identity for an entity
1️⃣ User provides identity
Let's see in details :
✅ Advantage(s): It appears to be a straightforward approach to have a user manually enter the details of unique identity. The user types a recognizable value or symbol into an input field or selects from a set of available characteristics, and the Entity is created.
❌ Disadvantage(s): One complication is relying on users to produce quality identities. The identity may be unique but incorrect. Most times identities must be immutable, so users shouldn’t change them. Can users be relied upon to produce both unique and correct, long-lasting identities?
2️⃣ Application generates identity
In details
✅ Advantage(s): There are highly reliable ways to autogenerate unique identities, although care must be taken when the application is clustered or otherwise distributed across multiple computing nodes. There are identity creation patterns that can, to a much greater degree of certainty, produce a completely unique identity. The universally unique identifier (UUID), or globally unique identifier (GUID).
❌ Disadvantage(s): the identity is big and is not considered human-readable.
3️⃣ Persistence Mechanism Generates Identity
✅ Advantage(s): Delegating the generation of unique identity to a persistence mechanism has some unique advantages. If we call on the database for a sequence or incrementing value, it will always be unique. Depending on the range needed, the database can generate a unique 2-byte, 4-byte, or 8-byte value. In Java, a 2-byte short integer would allow for up to 32,767 unique identities; a 4-byte normal integer would afford 2,147,483,647 unique values; and an 8-byte long integer would provide up to 9,223,372,036,854,775,807 distinct identities. Even zero-filled text representations of these ranges are narrow, at five, ten, and 19 characters respectively.
❌ Disadvantage(s): One possible downside is performance. It can take significantly longer to go to the database to get each value than to generate identities in the application. Much depends on database load and application demand. One way around this is to cache sequence/increment values in the application, such as in a Repository.
4️⃣ Another Bounded Context assigns Identity
✅ Advantage(s) : When another Bounded Context assigns identity, we need to integrate to find, match, and assign each identity. DDD integrations are explained in Context Maps and Integrating Bounded Contexts. Making an exact match is the most desirable. Users need to provide one or more attributes, such as an account number, username, e-mail address, or other unique symbol, to pinpoint the intended result.
❌ Disadvantage(s): This has synchronization implications. What happens if externally referenced objects transition in ways that affect local Entities? How will we know that the associated object changed?
💡 solution(s): This problem can be solved using an Event-Driven Architecture with Domain Events. Our local Bounded Context
subscribes to Domain Events published by external systems. When a relevant notification is received, our local system transitions its own Aggregate Entities to reflect the state of those in external systems.
Conclusion : An Entity is an object that has a unique identity that runs through time and different states. Is mutable — its attributes may change, but it remains the same entity. Is distinguished by its ID rather than its attributes.
See you next time 😁
Top comments (0)