Currying your monolithic code with basic DDD principles

Even the most monolithic code base could benefit by introducing some of the most basic principles of Domain Driven Design. The following blog post is a reproduction of a real life code base, in a simplified form, but not far from reality.

The breakdown

public void Update(CustomerDto customer)
{
  Customer existingCustomer = _customerRepository.GetById(customer.Id);
  if (existingCustomer == null) throw new InvalidOperationException("Customer does not exist");

  // Check to see if we have changes
  bool hasChanges = !existingCustomer.Street.Equals(customer.Street)
                    || !existingCustomer.StreetNumber.Equals(customer.StreetNumber)
                    || !existingCustomer.City.Equals(customer.City)
                    || !existingCustomer.PostalCode.Equals(customer.PostalCode)
                    || !existingCustomer.Country.Equals(customer.Country);

  // Update object
  existingCustomer.Street = customer.Street;
  existingCustomer.StreetNumber = customer.StreetNumber;
  existingCustomer.PostalCode = customer.PostalCode;
  existingCustomer.City = customer.City;
  existingCustomer.Country = customer.Country;

  // If we have address changes update invoicing service
  if (hasChanges)
  {
      _invoicingService.Execute(new UpdateAddress
          {
              Id = customer.Id,
              Street = customer.Street,
              Number = customer.StreetNumber,
              Postal = customer.PostalCode,
              City = customer.City,
              Country = customer.Country
          });
  }

  _unitOfWork.SaveChanges();
}

By seeing the above code snippet, even without knowing all the specific implementations, we can clearly identify the requirements of this method:

Map all necessary values from the data-transfer object to the domain
When a customer’s address has been been changed we need inform the invoicing service of that change
We need to persist the changes if any

Just for the sake of clarity i will include the initial anemic domain model

public class Customer
{
  public int Id { get; set; }
  public string Street { get; set; }
  public string StreetNumber { get; set; }
  public string PostalCode { get; set; }
  public string City { get; set; }
  public string Country { get; set; }
}

The ‘Address’ value object

By introducing a DDD value object for all the address related properties we could simplify all the necessary change tracking in this code, i will include the Address code snippet just for clarity but i let my Resharper generate all equality members.

public class Address
{
  public Address(string street
      , string streetNumber, string postalCode
      , string city, string country)
  {
    Street = street;
    StreetNumber = streetNumber;
    PostalCode = postalCode;
    City = city;
    Country = country;
  }

  public string Street { get; private set; }
  public string StreetNumber { get; private set; }
  public string PostalCode { get; private set; }
  public string City { get; private set; }
  public string Country { get; private set; }

  protected bool Equals(Address other)
  {
    return string.Equals(Street, other.Street) && string.Equals(StreetNumber, other.StreetNumber) &&
            string.Equals(PostalCode, other.PostalCode) && string.Equals(City, other.City) &&
            string.Equals(Country, other.Country);
  }

  public override bool Equals(object obj)
  {
    if (ReferenceEquals(null, obj)) return false;
    if (ReferenceEquals(this, obj)) return true;
    if (obj.GetType() != typeof (Address)) return false;
    return Equals((Address) obj);
  }

  public override int GetHashCode()
  {
    unchecked
    {
      int hashCode = (Street != null ? Street.GetHashCode() : 0);
      hashCode = (hashCode*397) ^ (StreetNumber != null ? StreetNumber.GetHashCode() : 0);
      hashCode = (hashCode*397) ^ (PostalCode != null ? PostalCode.GetHashCode() : 0);
      hashCode = (hashCode*397) ^ (City != null ? City.GetHashCode() : 0);
      hashCode = (hashCode*397) ^ (Country != null ? Country.GetHashCode() : 0);
      return hashCode;
    }
  }

  public static bool operator ==(Address left, Address right)
  {
    return Equals(left, right);
  }

  public static bool operator !=(Address left, Address right)
  {
    return !Equals(left, right);
  }
}

This is how our Customer domain object could look like at this moment:

public class Customer
{
  public int Id { get; set; }
  public Address Address { get; set; }
}

By doing this we can refactor our main monolithic block to this:

public void Update(CustomerDto customer)
{
  Customer existingCustomer = _customerRepository.GetById(customer.Id);
  if (existingCustomer == null) throw new InvalidOperationException("Customer does not exist");

  // Check to see if we have changes
  var newAddress = new Address(customer.Street
                  , customer.StreetNumber
                  , customer.PostalCode
                  , customer.City
                  , customer.Country);

  bool hasChanges = existingCustomer.Address != newAddress;

  // Update object
  existingCustomer.Address = newAddress;

  // If we have address changes update invoicing service
  if (hasChanges)
  {
    _invoicingService.Execute(new UpdateAddress
      {
          Id = customer.Id,
          Street = customer.Street,
          Number = customer.StreetNumber,
          Postal = customer.PostalCode,
          City = customer.City,
          Country = customer.Country
      });
  }

  _unitOfWork.SaveChanges();
}

Introduce a domain event and put the logic where it belongs

For more details i encourage you to read Udi Dahan’s post on it.

The ‘CustomerMoved’ domain event:

This event indicates that a customer has moved

public class CustomerMoved : IDomainEvent
{
  public int Id { get; set; }
  public Address Address { get; set; }
}

It’s handler

Which has only the responsability to let the invoicing system know when a customer has moved.

public class UpdateInvoicingAddressHandler : IDomainEventHandler<CustomerMoved>
{
  private readonly InvoicingService _invoicingService;

  public UpdateInvoicingAddressHandler(InvoicingService invoicingService)
  {
    _invoicingService = invoicingService;
  }

  public void On(CustomerMoved @event)
  {
    _invoicingService.Execute(new UpdateAddress
          {
              Id = @event.Id,
              Street = @event.Address.Street,
              Number = @event.Address.StreetNumber,
              Postal = @event.Address.PostalCode,
              City = @event.Address.City,
              Country = @event.Address.Country
          });
  }
}

Remove setters

Let’s create a move method that does all necessary mechanics and remove the address property setter

public class Customer
{
  public int Id { get; set; }
  public Address Address { get; private set; }

  public void Move(Address newAddress)
  {
    if (Address == newAddress) return;
    Address = newAddress;
    DomainEvents.Raise(new CustomerMoved {Id = Id, Address = newAddress});
  }
}

The result, which is no longer monolithic

public void Update(CustomerDto customer)
{
  Customer existingCustomer = _customerRepository.GetById(customer.Id);
  if (existingCustomer == null) throw new InvalidOperationException("Customer does not exist");

  var newAddress = new Address(customer.Street, customer.StreetNumber
                              , customer.PostalCode, customer.City, customer.Country);

  existingCustomer.Move(newAddress);

  _unitOfWork.SaveChanges();
}

I hope that i convinced or can inspire some of you, we could and should all benefit from the principles applied in DDD.