Entities and Value Objects

by Dasith Gunawardana
Today we are going to discuss about the Entitles and the Value objects. You can find todays presentation in our previous post.

Here is the overview of what we are going to discuss today.

• Domain Driven Design
• Model Driven Design
• Elements of a Model
• Entities
• Value Objects
• Entities Vs Value Objects

So as I start with my presentation, let’s look at what is a Domain Driven Design. Actually Domain Driven Design is an approach to the design of the software based on two premises. In Domain Driven Design the primary focus should be on the domain and the domain logic. The Domain is the area in which the system is going to implement and the domain logic is the process of the system.

In most occasions complex domains are based on a Model because of convenience of understanding the system features.

In a Model Driven Design Analyst responsibility is to capture the fundamental concepts of the domain in a comprehensive manner.

But the designer has to specify set of components that can be constructed with the programming tools to use in the project.

Therefore a Model Driven Design eliminates both issues in Analysis model and design to come up with a single solution which serve both purposes.

Actually a Model Driven Design is software that structures around set of concepts which gives more concern to translate the Model in to code for different technological platforms.

This is the high level view of expansion of the Model Driven Design.

The Model Driven Design comprises of Services, Entities, Value Objects, Layered Architecture and Smart UI which again expand the Entities ad Value objects to Repositories, Aggregates and Factories. But here in our presentation we will be mainly focusing the Entity and Value Objects.

by Eranga Wijebandara - 044046

What is entity?
Many objects are not fundamentally defined by their attributes, but rather by a thread of continuity and identity.

This entity object can be easily understand using general example. Take a person he has lot of attributes such as name, color, etc...These attributes are changed during the life time. But even these attributes has changed we can identify that particular person.The reason for that is identity persists.

As same manner object can be identify using it's identity. So during the life cycle of the object the identity will never change.But attributes can be change such as definition,responsibilities , association etc.

Mistaken identity will make lot of problem.

Example:
"A landlady sued me, claiming major damages to her property. The papers I was served described an apartment with holes in the walls, stains on the carpet, and a noxious liquid in the sink that gave off caustic fumes that had made the kitchen wallpaper peel. The court documents named me as the tenant responsible for the damages, identifying me by name and by my then-current address. This was confusing to me, because I had never even visited that ruined place.

After a moment, I realized that it must be a case of mistaken identity. I called the plaintiff and told her this, but she didn't believe me. The former tenant had been eluding her for months. How could I prove that I was not the same person who had cost her so much money? I was the only Eric Evans in the phone book.

Well, the phone book turned out to be my salvation. Because I had been living in the same apartment for two years, I asked her if she still had the previous year's book. After she found it and verified that my listing was the same (right next to my namesake's listing), she realized that I was not the person she wanted to sue, apologized, and promised to drop the case."(Reference:Domain Driven Design by Eric Evans)

So same thing apply to object as well .A case of mistaken identity in a software system lead to data corruption and program error.

by Chathurika Sandarenu - 044034

We now know that the Identity is the most important thing in an Entity. This identity of an Entity can even be applicable outside the application domain. For example we can consider in a Banking application it use account no to uniquely identify accounts. We use this identity; account number to identify an account in general, in our day today lives.

But some identities do not have a meaning when we take it out of that particular application. For example in Operating Systems, it gives unique ID to each process running. If we take that process id alone, without considering the OS it do not have any meaning.

This Identity of an Entity we are talking about is directly depends on the application domain. Depending on application we may choose some objects as entities and same object may not be choosen as an Entity in another application. The idea of Identity does not necessarily have to mach with our real world experience. Things we consider as unique may not consider as unique in some software applications. What is choosen as Entity and their Identity is directly depends on the domain model.

For example if take the object “Seat” in a “Seat Booking” application we have to take it as an Entity since we need to uniquely identify individual seats. But if we consider “General Admission” scenario “Seat” need not to be an Entity. Since in “General Admission” we consider all seats same, we do not need to find out the identity of individual seats.

Litmus test of Entity is the Identity. Doesn’t matter the attribute values are changed in two instances of objects, if those two instances have same identity then they are from same Entity. We can use the same concept with humans, over the time our appearance changes, skin wrinkles, hair color changes, and so many things happen, but still our identity remains same….

Modeling Identity

This is the most important thing regarding Entities. Entities are the most important objects in our domain. When modeling them we have to make sure that they are both lean and powerful. When modeling Entity it is better to keep it as simple as possible. Only put attributes that are necessary to represent the identity. Put anything else into separate objects. Those separate objects can either be Entities or Value Objects. So this way we can have a hierarchy of objects which are attached to one CORE ENTITY. This is also known as aggregate.

Next Important thing, when modeling Entity is what to choose to represent Identity of the Entity. This can be done in many ways depending on the application. One method is to use some attributes or combination of attributes as identity. For example we can use NIC as Identity for Person object, or we may use combination of attributes such as Name and DOB. Another method is to use auto generated IDs. When we use database applications we can use DBMS to auto generate keys and we can use that same key as Identity of our Entity.

by Wajira Somarathne - 044038

Value Objects:

Lets talk about value objects. First think about following 3 circles.

They can be uniquely identified. Because they are colored in 3 different colours. So we can identify each circle by its own colour. Now we will think about this scenario: now think about following 3 circles.

Can you identify each other separately. No .. We can’t. Because each circle is same as others. Lets think we are creating a new shape using this 3 circles like this.

Can you find which circle is on the top, which is at the left and which is at the right? We cannot. And there is no effect whether 1^st circle is on the top or left or right. These kinds of scenarios will be occur in the object modeling also.

We use value objects to address this kind of scenarios by giving more performance to the system. According to the common definition, An object that represents a descriptive aspect of the domain with no conceptual identity is called a value object. Value objects are instantiated to represent elements of the design that we care about only for what they are, not who or which they are. That means value objects are not concerning about the identity of each real world things. Value objects are commonly share the attributes of them.

Lets take an example: In software for a mail-order company, an address is needed to confirm the credit card, and to address the parcel. But if a roommate also orders from the same company, it is not important to realize they are in the same location. So Address is a VALUE OBJECT in this case.

By W.G.K.D. Karunarathne - 044022

Consider the Scenario 3.In a software for an electric utility company an address can be considered as an entity object because it corresponds to a destination for the company’s lines and service. If roommates each called to order electrical service, the company would need to realize it. Address is an entity. Alternatively, the model could associate utility service with a "dwelling," an entity with an attribute of address .In this case address can be consider as a value object.

In model driven design approach it is better to use value objects. Even though many programmers think entity objects are better but value object are much powerful than entity objects. We can use value objects in communication to increase the network performance. We can make copies from value objects (not like entity objects) and can send copies of value objects to the client side from server side. On the other hand if we use entity objects need to send objects for client’s each and every request separately. This will caused to increase the server load.

Value objects must be immutable. We cannot change the existing value objects. If we need to change them we need to destroy the object and recreate them. So we can send copies of value objects in communication. As we can use value objects for data transfer we called them as data transfer objects. Value objects can be assembling from other objects. They can be made up of other value objects as well as other entity objects.

Both entity and value objects are principles. We can’t say these are important and these are not important. Entity identity is important and value objects are only for values. But value objects will be more programmatically efficient.

by Anushke L. N. Guneratne - 044014

Odds and ends on Value objects and a Conclusion

As we can see from the posts of others in my group, it is clear that the seperation of entity and value objects is done at the design stage, specially where it is in reference to model driven design.

There are cases when we need to contain some attributes of a domain element. We are not interested in which object it is, but what attributes it has. An object that is used to describe certain aspects of a domain, and which does not have identity, is named Value Object.

Having no identity, Value Objects can be easily created and discarded. Nobody cares about creating an identity, and the garbage collector takes care of the object when is no longer referenced by any other object.

Value objects can be part of a entity object, or it can refernce to entity objects.

Bottom line is in conclusion,
- Value objects are programatically efficient, and are sometimes called Data Tansfer Objects.
- Entity Objects are NOT just an important object, but rather Objects where the Identity is important
- Whilst Value objects are objects where the value is important.