This post is just to share my notes on the course “Refactoring from Anemic Domain Model Towards a Rich One” by Vladimir Khorikov.
Module #2 – Introduction
– Problems with an anemic domain model: discoverability of operations, potential duplication, lack of encapsulation.
– Encapsulation is about protecting data integrity (no operation should be able to violate the invariants of a class, an aggregate). Protecting you from doing something incorrectly.
– Encapsulation is so important to maintain because without it we can’t cope with the increasing complexity of the code base (slows down development, increases the number of bugs).
– Anemic domain model always means the lack of encapsulation.
– If classes with data do not impose any restriction, the services with operations are the ones that should know how to keep the integrity and always remember to do it (potential duplication).
– An anemic model can be adequate for small projects that are not going to be developed for a long time. Also, different bounded contexts can have different needs.
– Anemic Domain Model and Functional Programming?. FP encourages immutable data structures and operations separated from them. Vladimir mentions that with FP immutability there is no need to worry about corruption of internal state, hence FP does not suffer from the lack of encapsulation. It suffers from discoverability of operations.
– In my experience I believe that immutability alone does not prevent us from breaking the invariants, an operation can’t change an object but can return a new copy changing one property in a way that breaks integrity. To solve that issue I would say that we should always use a constructor (which enforces invariants) to instantiate objects and not use the cloning mechanism provided by the language to bypass invariants validation.
Continue reading “My notes on “Refactoring from Anemic Domain Model” by Vladimir Khorikov”