Do immutable objects and DDD go together?

Question

Consider a system that uses DDD (as well: any system that uses an ORM). The point of any system realistically, in nearly every use case, will be to manipulate those domain objects. Otherwise there's no real effect or purpose.

Modifying an immutable object will cause it to generate a new record after the object is persisted which creates massive bloat in the datasource (unless you delete previous records after modifications).

I can see the benefit of using immutable objects, but in this sense, I can't ever see a useful case for using immutable objects. Is this wrong?

Answer 1

Computation using immutable objects (as in functional programming) does not necessarily imply persisting every object that is generated!

Answer 2

Does immutable in the domain mean it has to be immutable in the database? For example consider the following assuming customer always has one address:

customer.address = new Address('My Castle', 'Kings street');
customer_repo.save(customer);

now the following sql is run considering the customer id is 1:

INSERT INTO addresses (customer_id, name, street)
VALUES (1, 'My Castle', 'Kings street');

now the following change is made to the address:

customer.address = new Address('Pauper palace', 'Outlands');
customer_repo.save(customer);

and the persistence layer, being very clever runs the following sql:

UPDATE addresses SET name='Pauper palance', street='Outlands'
WHERE customer_id = 1;

This way you avoid the overhead of a separate DELETE AND INSERT statement. Also I think some RDBMSs have INSERT REPLACE or something. MySql has REPLACE.

Answer 3

In DDD, immutable objects pretty much equate with value objects. These objects aren't entities, they don't have an identity. Therefore I always persist value objects as colums of the entity they are contained in (with N/Hibernate you can use Components for that). They don't have a table of their own.

Answer 4

It depends on how the immutable object is mapped in the database. If it's just a component like a DateTime (from the Joda Time library) then changing the value will result in an update rather than an insert. However, if the immutable is more complex requiring a row in a table then you've got the bloat problem.

I suppose, although it is a weak argument, you could implement an audit trail this way. Every change to the immmutable can be tracked through the inserts. There are many better ways to do this though.

All in all having immutable domain objects (instead of merely their components) seems a bit of a mismatch with persistence.

Answer 5

That depends on the domain. DDD doesn't specify that the programming paradigm is object oriented. The object oriented paradigm is however one well suited for the typical application that must be persisted in a database.

DDD simply states that you should build your software around a domain model that represents the actual problem that the software is trying to solve. If that problem was for example mathematical by nature, then implementing the domain layer using functional programming and immutable data structures would make a lot of sense.

If on the other hand, the problem is more of a typical enterprise application, and you are using immutable object structures for all your domain objects, then I would argue that you are not following DDD. I can come up with at least two arguments:

• Your implementation does not represent a domain model of your problem domain. Your problem domain in this case consists of entities having state to modify. And that is not how you have implemented it.

• You do not have an ubiquitous language. The language and the concepts in the domain model do not follow what the domain experts are using.

Note: DDD does use immutable objects where appropriate, they are just called value objects.

So I'm not saying that you cannot create a database application using purely functional data structures, and I'm not saying that you shouldn't. I just don't think you can call it DDD, depending on the type of application

Answer 6

If you are using an ORM such as Hibernate / NHibernate you can set your cascade option to automatically delete orphaned objects. If a person has a value object Address, when you change the address, the new one will be saved and the old one deleted because it is now orphaned.

Answer 7

Value objects are almost always immutable in DDD and the flyweight pattern can be used to keep duplication of that value object down in memory just like .NET does with strings. The main tradeoff is memory one one side and the other side is creational efficiency. With the flyweight pattern, a value based comparison must be done to determine whether any new or reconstituted value object is already within the flyweight cache but any other comparison after that point can be generally safely done by reference since a single instance is enforced. Either way whether flyweight is used or not, value objects are still made immutable because they have only intrinsic identity and thus changing their value would change their identity.

Answer 8

There is another way to use immutable objects...

Instead of storing a values 5.0, 6.0, 7.0, 8.0 and copying the whole record every time, you can instead store something like this: 5.0, +1.0, +1.0, +1.0, and then build a dependencies correctly to reconstruct the sequence 5.0, 6.0, 7.0, 8.0. This way small modifications only take small amount of memory...