My notes on “Refactoring from Anemic Domain Model” by Vladimir Khorikov

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”

Design Patterns – Facade

The Facade Pattern is used to provide a simplified interface to a complicated subsystem.

The idea is to define a higher-level interface that abstracts clients from using directly a set of lower level interfaces in the subsystem. For some clients accessing directly the subsystem could make perfect sense because they benefit from the different options and flexibility of a rich API. However, most of the clients only need basic functionality, accessing a large set of interfaces only bring them complexity.

This pattern is commonly used during refactoring to simplify the use of a legacy code subsystem.

One important difference between this structural pattern and the Decorator pattern is that the goal in Facade is not to add new functionality.

Real examples

* JQuery
JQuery is a good example of Facade Pattern, providing a simple and clean interface to interacting with the complex DOM of the browser.

* Java URL class

URL url = new URL("http", "", 80, "/";);

Code example

class FlightsService {
  findFlightsFor(city, date) {
    console.log(`Searching for flight to ${city} on ${date}`);

  book(flightNumber, airline, date) {
    console.log(`Booking flight ${flightNumber} - ${airline} on ${date}`);

class HotelsService {
  findHotelsFor(city, checkinDate, checkoutDate) {
    console.log(`Searching for hotels on ${city} from ${checkinDate} to ${checkoutDate}`);

  book(roomNumber, hotel, checkinDate, checkoutDate) {
    console.log(`Booking room ${roomNumber} - ${hotel} from ${checkinDate} to ${checkoutDate}`);

class TravelFacade {
  constructor() {
    this.flightsService = new FlightsService();
    this.hotelsService = new HotelsService();

  findFlightsAndHotels(city, travelDate, returnDate) {
    this.flightsService.findFlightsFor(city, travelDate);
    this.flightsService.findFlightsFor(city, returnDate);
    this.hotelsService.findHotelsFor(city, travelDate, returnDate);