Entity and Value Object are not part of the Ubiqtious language. Should this stop me from using them?

Question

I was talking to a Business Analyst about our Domain Model a few weeks ago. I used a class diagram to facilitate communication. She understands UML at a high level and this worked out quite well. She only asked two questions: what is an Entity and what is a Value Object? I explained.

I have two base classes i.e. Entity (http://enterprisecraftsmanship.com/2014/11/08/domain-object-base-class/) and Value Object (https://lostechies.com/jimmybogard/2007/06/25/generic-value-object-equality/). This seems to be working very well today.

However, a couple of people criticized this approach earlier on my other question here: Should I handle all nine comparisons?. They argued that these bases classes:

1) Make the Domain Model anaemic as another class is responsible for comparisons. 2) Entity and Value Object are not part of the Ubiquitous language

Point two has some bearing for me because of the conversation I had with the Business Analyst. Therefore I have looked at examples of DDD apps on GitHub with this in mind and I can't find any real life examples that use this approach. However, some tutorial type apps use it like this one: https://github.com/vkhorikov/DddInAction/tree/master/DddInPractice.Logic/Common

Therefore I have to ask if this is a valid approach for a real life application or whether it is just a thought exercise?

It does not really matter whether or not I use these base types at the moment. However, I don't want to introduce problems now that only become apparent when the application scales more in future.

Answer 1

If I'm understanding you right, every class in your domain is based on on of two classes.

1. Entity which enforces a single type Id field, tightly coupled to your database and various equality overrides and reflection of classes

2. Value which emulates a value type and attempts to enforce immutably

I am struggling to understand the motivations for this idea.

The Entity suggestion seems to be a throw back to the Active record pattern, with its tight coupling to Nhibernate, assumption that your primary key can be a long int for all objects and that a value of 0 means the object isn't 'real' because the database needs to generate ids.

The Value object seems like a clumsy attempt to replace struct. You are worried about > 16byte structs being slow and replacing them with reflection?

Both override operators, something that it rarely advisable.

There are some edge cases where you will lament that you business object is a reference class and want to create a copy constructor.

There are some rare edge cases where you want to compare objects and simply comparing the Id isn't enough.

But these aren't the kind of massive unforeseen 'gotchas' that require you to plan the entire structure of your code ahead incase they turn up.

The distinction between Value and Reference Types shouldn't be something that comes up in a discussion with a Business Analyst.

Update : Summary of the comments

When comparing domain objects in your application my recommendation is to compare the Id fields ie.

var cust1 = repo.GetCustomerByName(name);
var cust2 = repo.GetCustomerByLastName(lastname);

var areCustomersTheSame = cust1.Id == cust2.Id

rather than comparing the objects directly. ie.

var cust1 = repo.GetCustomerByName(name);
var cust2 = repo.GetCustomerByLastName(lastname);

var areCustomersTheSame = cust1 == cust2

The second method requires that you override the default operators which is more work and will not be expected. Additionally it means you cant do the default compare to see if the reference is the same.

There is a third complication where the Ids may match but some other fields on the object have changed, or you have no Id field at all. Here I would encapsulate that logic in another class.

CustomerComparer.IsAllFieldsMatch(cust1,cust2)

My General feeling is that if you are having to check whether objects are the same often in your Business Logic. You are doing something wrong somewhere. Get Objects once, do your thing and dispose of them.

Answer 2

Entity and Value Object are not part of the Ubiqtious language. Should this stop me from using them?

You shouldn't be using terms from the implementation domain to try to explain what's going on in the business domain.

Entity and Value Object are names for implementation patterns, much like Iterator, Command, Domain Model....

Another way of thinking of Entity and ValueObjects is that they describe roles that the implementations can play. For instance, if CustomerProfile is an Entity, then that could mean that it implements an identity() method that returns some identifier that is a Value Object, which in turn promises that the identifier is immutable, and suitable for use as key into a data structure. So you can build a generic Repository that can act like an in memory collection of an object that implements the Entity role by providing an identifier that supports the Value Object role

interface Entity<Id implements ValueObject> {...}

interface CustomerProfile {...}

HibernateCustomerProfile implements CustomerProfile, Entity<HibernateCustomerId> {...}

class HibernateCustomerProfileRepository extends Repository<CustomerProfile> {...}

But these conveniences are almost always down in the plumbing, not part of implementing the domain behaviors.

Is it suitable to use ValueObject and Entity bases classes in a real implementation or is it just a thought exercise? Do you use them?

I don't use them as base classes; I normally work in languages where I'm restricted to a single base class for any given implementation, and the value of a common base class doesn't offset the costs.

As interfaces, they are just metadata. They don't have any state of their own.

In an implementation language with mixins, they might be useful. I'm skeptical, but I don't have enough experience with them to advertise an informed opinion.