-1

In the SE classes at university we were taught OOAD and DDD (using Java) and encouraged to use it in our projects. Unfortunately a lot of challenges caused by the mutability of entities were not discussed:

  • Unsuitability for multithreaded applications
  • That it breaks data structures that rely on equals(), hashCode() or compareTo() (*)
  • That it makes it hard to reason about the state of entities

These problems make it very hard for me to use DDD although I like the ideas behind it and a lot of libraries and frameworks (like ORM, serialization libraries -- basically everything that uses Java Beans) rely on the mutability of entities. The result is that I'm full of doubts when making architectural decisions and never happy with the outcome, no matter what I do. Either I get some Frankenstein's monster app where I have the entities immutable, but a lot of mutable glue to make it work (Builder, mutable DAO/DTO), or I have a fully mutable app full of WTFs (like sorting a list every time I use it instead of using a sorted data structure because an entity might have been changed since it was added to the list).

How do you deal with these problems? What's the way to go? Are there alternatives to DDD that don't require mutability?

I would personally prefer to go fully immutable, but that would make it very hard or even impossible to use some libraries that require Java Beans. Of course I could switch to functional programming but I'm not sure wheather it's a good replacement for the typical projects where DDD is used.

(*) Well, only if you override them. But where's the point in using a set if you don't?

aha
  • 3,702
  • 3
  • 38
  • 47

2 Answers2

2

I'm not sure what you mean by "immutable entities" but it sounds like an oxymoron to me. Entities are about identity, you're supposed to be able to identify and track them for their entire lifetime, when they are created, modified, persisted, rehydrated... You can sure track and persist something that never changes, but I fail to see the interest -the basic reason for identity to exist is precisely to put a fixed label on something that changes.

Some domain objects are actually suitable for immutability though, but not entities, rather value objects, objects whose identity doesn't matter. You can easily substitute a value object instance for another, equal one without consequences.

If what you're trying to do is make every domain object an immutable value object, this is certainly not DDD any more. DDD's about object oriented, not purely functional programming :)

guillaume31
  • 13,738
  • 1
  • 32
  • 51
  • Thanks for your answer, but I think it focuses on the wrong aspect of my question. My question was: How do you deal with the implications of the mutability of entities? For example that you cannot use sorted collections or that you cannot implement Comparable or Comparator for entities because that would violate their contract as long as you use fields for the comparison. Does DDD really mean that you have to leave all that infrastructure behind even if its use would be legit (like sorting Persons by name)? – aha May 31 '12 at 09:07
  • To me, DDD, mutability and sorting/comparing are 3 orthogonal concerns. How do they play together ? DDD vs. mutability => see my previous answer. DDD vs. sorting/comparing => the equality rule saying that 2 entities are equal if their identities are equal doesn't forbid you to do custom comparisons based on their fields for sorting purposes. Mutability vs. sorting/comparing => real-time sorting for sets is feasible but seems costly. See http://stackoverflow.com/questions/7883835/real-time-sorted-by-value-auto-discarding-bounded-collection This has nothing to do with DDD though. – guillaume31 May 31 '12 at 09:45
0

Those are common issues. I assume you consider the following scenario:

  • Construct 'Order' object from persistent data
  • Make some changes to 'Order'
  • Persist changes made.

If there are two simultaneous requests walking through the same scenario, then:

  • Unsuitability for multithreaded applications: First, you have two different instances, second, you'd use optimistic/passimistic lock when saving data.
  • That it breaks data structures that rely on equals(), hashCode() or compareTo() - two domain entities are equal if their identifiers are equal (otherwise you have value types which are immutable by definition).
  • That it makes it hard to reason about the state of entities - not sure why you need this. O/RM tracks that for data update purpose automatically, DDD is storage-unaware. If changes tracking is a part of business logic, then that's needed to be implemented, yes.
mikalai
  • 1,746
  • 13
  • 23