One way to factor out the alien responsibility is to use error codes in Validation instead. Those error codes could be nicely organized in the collection of properties of a static class. I will also change the Error property name in Result to ErrorCode to convey my intent. (As you remember you can only improve readability and maintainability if you use maximum explicitness).

public class Result
{
    private readonly string _errorCode;

    public string ErrorCode
    {
        get
        {
            if (IsSuccess)
                throw new InvalidOperationException("No error when success");
            return _errorCode;
        }
    }

    public bool IsSuccess => string.IsNullOrEmpty(_errorCode);

    protected Result(string error)
    {
        _errorCode = error;
    }

    public static Result<T> Success<T>(T value) => new Result<T>(value, null);
    public static Result Success() => new Result(null);
    public static Result<T> Failure<T>(string error) => new Result<T>(default, error);
    public static Result Failure(string error)
    {
        if (string.IsNullOrEmpty(error))
            throw new ArgumentNullException(nameof(error));

        return new Result(error);
    }

    public override bool Equals(object obj)
    {
        if (obj is Result other)
        {
            return IsSuccess == other.IsSuccess && _errorCode == other._errorCode;
        }
        return false;
    }

    public override int GetHashCode()
    {
        return _errorCode?.GetHashCode() ?? 0;
    }
}

public static class Error
{
    public static class InEmail
    {
        public static Result EmailNullOrWhitespace { get; } = Result.Failure("EMAIL_NULL_OR_WHITESPACE");
        public static Result InvalidEmailFormat { get; } = Result.Failure("INVALID_EMAIL_FORMAT");
    }

    public static class InCustomerName
    {
        private const string LAST_NAME = "LAST_NAME";
        public static Result LastNameNullOrWhitespace { get; } = NameNullOrWhitespace(LAST_NAME);
        public static Result LastNameMaxLengthExceeded { get; } = NameMaxLengthExceeded(LAST_NAME);
        public static Result LastNameHasInvalidCharacters { get; } = NameHasInvalidCharacters(LAST_NAME);


        private const string FIRST_NAME = "FIRST_NAME";
        public static Result FirstNameNullOrWhitespace { get; } = NameNullOrWhitespace(FIRST_NAME);
        public static Result FirstNameMaxLengthExceeded { get; } = NameMaxLengthExceeded(FIRST_NAME);
        public static Result FirstNameHasInvalidCharacters { get; } = NameHasInvalidCharacters(FIRST_NAME);

        private static Result NameNullOrWhitespace(string namePart) => Result.Failure($"{namePart}_NULL_OR_WHITESPACE");
        private static Result NameMaxLengthExceeded(string namePart) => Result.Failure($"{namePart}_MAX_LENGTH_EXCEEDED");
        private static Result NameHasInvalidCharacters(string namePart) => Result.Failure($"{namePart}_HAS_INVALID_CHARACTERS");
    }
}

Given those changes I can easily rewrite the factory methods as follows

public record struct Email
{
    private const string EMAIL_PATTERN = @"^[^@\s]+@[^@\s]+\.[^@\s]+$";

    private readonly string _value;

    private Email(string value)
    {
        _value = value;
    }

    private static Result CanCreate(string value)
    {
        if (string.IsNullOrWhiteSpace(value))
        {
            return Error.InEmail.EmailNullOrWhitespace;
        }

        if (!IsValidEmail(value))
        {
            return Error.InEmail.InvalidEmailFormat;
        }

        return Result.Success();
    }

    public Email() : this(null) { }

    public static Result<Email> Create(string value)
    {
        var result = CanCreate(value);
        if (!result.IsSuccess)
        {
            return Result.Failure<Email>(result.ErrorCode);
        }

        return Result.Success(new Email(value));
    }

    public override string ToString()
    {
        return _value;
    }

    private static bool IsValidEmail(string email)
    {
        return Regex.IsMatch(email, EMAIL_PATTERN);
    }

    public static implicit operator string(Email email)
    {
        return email._value;
    }

    public static explicit operator Email(string email)
    {
        var result = Create(email);
        if (!result.IsSuccess)
        {
            throw new ArgumentException(result.ErrorCode);
        }

        return result.Value;
    }
}

//----------------------------------------------------

public record struct CustomerName
{
    private const int MAX_NAME_LENGTH = 100;
    private const string NamePattern = @"^[A-Z][a-zA-Z]*$";

    public string FirstName { get; }
    public string LastName { get; }

    private CustomerName(string firstName, string lastName)
    {
        FirstName = firstName;
        LastName = lastName;
    }

    private static Result CanCreate(string firstName, string lastName)
    {
        if (string.IsNullOrWhiteSpace(firstName))
        {
            return Error.InCustomerName.FirstNameNullOrWhitespace;
        }

        if (string.IsNullOrWhiteSpace(lastName))
        {
            return Error.InCustomerName.LastNameNullOrWhitespace;
        }

        if (firstName.Length > MAX_NAME_LENGTH)
        {
            return Error.InCustomerName.FirstNameMaxLengthExceeded;
        }

        if (lastName.Length > MAX_NAME_LENGTH)
        {
            return Error.InCustomerName.LastNameMaxLengthExceeded;
        }

        if (!IsValidName(firstName))
        {
            return Error.InCustomerName.FirstNameHasInvalidCharacters;
        }

        if (!IsValidName(lastName))
        {
            return Error.InCustomerName.LastNameHasInvalidCharacters;
        }

        return Result.Success();
    }

    //default 
    public CustomerName() : this(null, null) { }

    public static Result<CustomerName> Create(string firstName, string lastName)
    {
        var result = CanCreate(firstName, lastName);
        if (!result.IsSuccess)
        {
            return Result.Failure<CustomerName>(result.ErrorCode);
        }
        return Result.Success(new CustomerName(firstName, lastName));
    }

    public override string ToString()
    {
        return $"{FirstName} {LastName}";
    }

    private static bool IsValidName(string name)
    {
        return Regex.IsMatch(name, NamePattern);
    }

    public static implicit operator string(CustomerName customerName)
    {
        return customerName.ToString();
    }

    public static explicit operator CustomerName(string fullName)
    {
        var names = fullName.Split(' ');
        if (names.Length != 2)
        {
            throw new ArgumentException("Full name must contain exactly two parts: first name and last name.");
        }
        var result = Create(names[0], names[1]);
        if (!result.IsSuccess)
        {
            throw new ArgumentException(result.ErrorCode);
        }

        return result.Value;
    }
}

To convert error code to formatted message we can introduce an extension helper method in UI or other outer layer communicating with the external world. The below is just the simplest implementation possible. You can add infinite logic here to format, localize, or discriminate the messages on various conditions.

    public static class UserErrorMessages
    {
        private static string CannotBeNullOrEmpty(string propertyName) => $"{propertyName} cannot be null or whitespace";
        private static string TooLong(string propertyName) => $"{propertyName} too long";
        private static string NotInValidFormat(string propertyName) => $"{propertyName} is not in valid format.";

        private static Dictionary<Result, string> _errorMessageMappings = new Dictionary<Result, string>()
        {
             { Error.InEmail.EmailNullOrWhitespace, CannotBeNullOrEmpty("Email") },
             { Error.InEmail.EmailNullOrWhitespace, NotInValidFormat("Email") },

             { Error.InCustomerName.FirstNameNullOrWhitespace, CannotBeNullOrEmpty("First Name") },
             { Error.InCustomerName.FirstNameMaxLengthExceeded, TooLong("First Name") },
             { Error.InCustomerName.FirstNameHasInvalidCharacters, NotInValidFormat("First Name") },

             { Error.InCustomerName.LastNameNullOrWhitespace, CannotBeNullOrEmpty("Last Name") },
             { Error.InCustomerName.LastNameMaxLengthExceeded, TooLong("Last Name") },
             { Error.InCustomerName.LastNameHasInvalidCharacters, NotInValidFormat("Last Name") },
        };

        public static string GetErrorMessage(this Result result) => _errorMessageMappings[result];
    }

Finally, let’s review the sample presentation logic of a typical WPF application. The presentation logic is typically encapsulated in a view model.

public class CreateCustomerViewModel : INotifyPropertyChanged
{
    private readonly HomeInsuranceService _insuranceService;
    private string _firstName;
    private string _lastName;
    private string _email;
    private string _errorMessage;
    private bool _isProcessing;

    // Implementation of INotifyPropertyChanged for UI updates
    public event PropertyChangedEventHandler PropertyChanged;
    protected virtual void OnPropertyChanged(string propertyName)
    {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }

    public CreateCustomerViewModel(HomeInsuranceService insuranceService)
    {
        _insuranceService = insuranceService ?? throw new ArgumentNullException(nameof(insuranceService));

        // Initialize the create customer command
        CreateCustomerCommand = new RelayCommand(
            execute: async () => await CreateCustomerAsync(),
            canExecute: () => CanCreateCustomer()
        );
    }

    // Properties with validation and UI notification
    public string FirstName
    {
        get => _firstName;
        set
        {
            if (_firstName != value)
            {
                _firstName = value;
                OnPropertyChanged(nameof(FirstName));

            }
        }
    }

    public string LastName
    {
        get => _lastName;
        set
        {
            if (_lastName != value)
            {
                _lastName = value;
                OnPropertyChanged(nameof(LastName));

            }
        }
    }


    public string Email
    {
        get => _email;
        set
        {
            if (_email != value)
            {
                _email = value;
                OnPropertyChanged(nameof(Email));

            }
        }
    }

    public string ErrorMessage
    {
        get => _errorMessage;
        private set
        {
            if (_errorMessage != value)
            {
                _errorMessage = value;
                OnPropertyChanged(nameof(ErrorMessage));
            }
        }
    }

    public bool IsProcessing
    {
        get => _isProcessing;
        private set
        {
            if (_isProcessing != value)
            {
                _isProcessing = value;
                OnPropertyChanged(nameof(IsProcessing));

            }
        }
    }


    public ICommand CreateCustomerCommand { get; }

    private bool CanCreateCustomer()
    {
        if (IsProcessing) return false;

        return !string.IsNullOrWhiteSpace(FirstName) &&
               !string.IsNullOrWhiteSpace(LastName) &&
               !string.IsNullOrWhiteSpace(Email)
    }

    // Async method to handle customer creation
    private async Task CreateCustomerAsync()
    {
        try
        {
            IsProcessing = true;
            ErrorMessage = string.Empty;

            // Call the service method
            var result = await Task.Run(() => _insuranceService.CreateCustomer(
                FirstName, LastName,
                Street, City, State, Zip,
                Email,
                DateOfBirth,
                parsedIncome));

            if (result.IsSuccess)
            {
                ErrorMessage = string.Empty;
            }
            else
            {
                //mapping the result to formatted error notification
                ErrorMessage = result.GetErrorMessage();
            }
        }
        catch (Exception ex)
        {
            ErrorMessage = $"An unexpected error occurred";
        }
        finally
        {
            IsProcessing = false;
        }
    }
}

as indicated above the validation bits can be repeated on various levels. They are just needed to enhance user experience. Here there is a CanCreateCustomer method that ensures the required fields and reports validation error on a shorter notification loop. The message would pop up on a screen faster and that is beneficial for the user who does not have to wait for the round trip to the core domain. That is why such validation has good reason to exist even if it partially repeats the core domain validation.

Summary

• Here we saw a cleaner approach to validation in Domain-Driven Design (DDD) by using error codes instead of error messages in the core domain.

• The article highlights the drawbacks of mixing UI concerns with core domain logic when using error messages in factory methods of Value Objects.

• The proposed solution involves organizing error codes in a static class and renaming the Error property in Result to ErrorCode for clarity.

• An extension helper method can be introduced in the UI or outer layer to convert error codes into formatted messages, allowing for flexibility in message presentation.

• The article provides an example of presentation logic in a WPF application, emphasizing the importance of validation at various levels to enhance user experience.

• It explains the benefit of having validation logic in the presentation layer for faster feedback to the user, even if it partially overlaps with core domain validation.

If your domain is well-designed it will not allow for something bad to happen. It will maintain all the invariants and prevent any kind of system input abuse. But if you do that one thing will suffer and that thing is the user experience. Similarly, a child will suffer if he is given an electric toy car and that car does not have a cover or remote control and all of its wires are sticking out, and to be able to start the engine you need to connect two bare wires. Any mistake in the input of such a system will protect the domain by crashing the application on one of those many exception throws. Any mistake in operating such a car can lead to a burned fuse or break an electronic component. In both cases, you are fine. Your car will not explode, and you won’t get burned. The system won’t send unexpected emails or write incorrect data to the database because it fails fast. However, the user experience will dramatically deteriorate as that person will have to start from scratch.

Here is where the validation comes into play as a handy method to give a user a shield, a second chance, a protection so he can retry without going through the inconveniences of restarting the app (or buying another toy). It is up to you where to put that protection that prohibits calling domain methods before input looks good enough. The validation can be added on the client or server sides, or also on both sides and that is fine if we duplicate validation logic sometimes between too.

Validation does not only filter out bad input that can’t sift through that defense to reach a highly guarded core domain tier. Good validation also provides friendly hints, guidance, clues, and suggestions on how to fix the input that it passes through and engages domain logic without any friction. The domain logic should be very precise and limited and often the input controls allow too many varieties of inputs introducing the same issue as primitive types in a domain model. That is why to make your application successful among users, you need to work hard on changing the behavior of such controls to limit the manifold of all possible inputs according to your core domain expectations (i.e invariants) and to show helpful notifications to correct typing as soon as typo or error is detected. There is a huge space for creativity here as well as many 3d party UI frameworks.

Let’s see the evolution of code from no validation to good validation while writing code for the same use case of adding a customer to an insurance company system.

    public class HomeInsuranceService
    {
        private readonly Database _database;

        public HomeInsuranceService(Database database)
        {
            _database = database ?? throw new ArgumentNullException(nameof(database));
        }

        //parameters are passed from UI
        public void CreateCustomer(
            string firstName, string lastName,
            string street, string city, string state, string zip,
            string email, 
            DateTime dateOfBirth,
            decimal annualIncome)
        {
            var customerId = CustomerID.NewCustomerID();
            var customerName = CustomerName.Create(firstName, lastName);
            var customerEmail = Email.Create(email);
            var today = DateTime.Today;
            var customerDateOfBirth = DateOfBirth.Create(dateOfBirth, today);
            var customerHomeAddress = USHomeAddress.Create(street, city, state, zip);
            var customerAnnualIncome = AnnualIncome.Create(annualIncome);
            var customer = Customer.Create(customerId, customerName, customerHomeAddress, customerEmail, customerDateOfBirth, today, customerAnnualIncome);
            _database.SaveCustomer(customer);
        }
    }

You can see that value objects and Customer entities are created via factory methods instead of using a constructor. That is a typical practice in DDD and is done for many reasons.

• The factory method call is easier to read and does not include the programming language keyword “new.” It conveys the intent much better as it is closely related to the ubiquitous language of the domain experts.

• The factory method allows for better encapsulation. Depending on the implementation details and object creation strategies, you can return a singleton, a new instance, or various subtypes introducing polymorphic behavior.

• By using factory methods, you can separate the concerns of object creation from the object's behavior.

  However, the most convenient feature of the factory method in Value Object is closely related to validation because they are a great mechanism for reusing guarding checks. But let’s see a naive method to add validation into our functionality creating a customer from the input that arrived straight from UI. Again our goal is to prevent exception throwing in case of a bad input and possibly add some good error notification so a user can get an idea of what to fix before the next retry. Exceptions are also bad due to an incredibly negative effect on general performance. Thus validation comes in pretty handy for achieving optimal performance as well.

•           public class Result(string error)
            {
                public string Error { get; } = error;
                public bool Success => string.IsNullOrEmpty(error);
  
                public static Result OK = new Result(null);
                public static Result Failure(string error)
                {
                    if(string.IsNullOrEmpty(error))
                        throw new ArgumentNullException(nameof(error));
  
                    return new Result(error);
                }
            }
  
            public class HomeInsuranceService
            {
                public Result CreateCustomer(
                    string firstName, string lastName,
                    string street, string city, string state, string zip,
                    string email, 
                    DateTime dateOfBirth,
                    decimal annualIncome)
                {
                    var customerId = CustomerID.NewCustomerID();
                    var result = CustomerName.CanCreate(firstName, lastName);
                    if(!result.Success)
                        return result;
                    var customerName = CustomerName.Create(firstName, lastName);
  
                    result = Email.CanCreate(email);
                    if(!result.Success)
                        return result;
                    var customerEmail = Email.Create(email);
  
                    /*
                        Same approach for other value objects...
                    */
  
                    var customer = Customer.Create(customerId, customerName, customerHomeAddress, customerEmail, customerDateOfBirth, today, customerAnnualIncome);
                    _database.SaveCustomer(customer);
  
                    return Result.OK;
                 }
            }
  
            public record struct CustomerName
            {
                private const int MAX_NAME_LENGTH = 100;
                private const string NamePattern = @"^[A-Z][a-zA-Z]*$";
  
                public string FirstName { get; }
                public string LastName { get; }
  
                private CustomerName(string firstName, string lastName)
                {
                    if (string.IsNullOrWhiteSpace(firstName))
                    {
                        throw new ArgumentException("First name cannot be null or whitespace.", nameof(firstName));
                    }
  
                    if (string.IsNullOrWhiteSpace(lastName))
                    {
                        throw new ArgumentException("Last name cannot be null or whitespace.", nameof(lastName));
                    }
  
                    if (firstName.Length > MAX_NAME_LENGTH || lastName.Length > MAX_NAME_LENGTH)
                    {
                        throw new ArgumentException($"First and last names cannot exceed {MAX_NAME_LENGTH} characters.");
                    }
  
                    if (!IsValidName(firstName) || !IsValidName(lastName))
                    {
                        throw new ArgumentException("Names must contain only letters and start with a capital letter.");
                    }
  
                    FirstName = firstName;
                    LastName = lastName;
                }
  
                public static Result CanCreate(string firstName, string lastName)
                {
                    if (string.IsNullOrWhiteSpace(firstName))
                    {
                        return Result.Failure("First name cannot be null or whitespace.");
                    }
  
                    if (string.IsNullOrWhiteSpace(lastName))
                    {
                        return Result.Failure("Last name cannot be null or whitespace.");
                    }
  
                    if (firstName.Length > MAX_NAME_LENGTH || lastName.Length > MAX_NAME_LENGTH)
                    {
                        return Result.Failure($"First and last names cannot exceed {MAX_NAME_LENGTH} characters.");
                    }
  
                    if (!IsValidName(firstName) || !IsValidName(lastName))
                    {
                        return Result.Failure("Names must contain only letters and start with a capital letter.");
                    }
  
                    return Result.OK;
                }
  
                //default 
                public CustomerName():this(null, null) { }
  
                public static CustomerName Create(string firstName, string lastName)
                {
                    return new CustomerName(firstName, lastName);
                }
  
                public override string ToString()
                {
                    return $"{FirstName} {LastName}";
                }
  
                private static bool IsValidName(string name)
                {
                    return Regex.IsMatch(name, NamePattern);
                }
  
                public static implicit operator string(CustomerName customerName)
                {
                    return customerName.ToString();
                }
  
                public static explicit operator CustomerName(string fullName)
                {
                    var names = fullName.Split(' ');
                    if (names.Length != 2)
                    {
                        throw new ArgumentException("Full name must contain exactly two parts: first name and last name.");
                    }
                    return Create(names[0], names[1]);
                }
            }
  
            public record struct Email
            {
                private const string EMAIL_PATTERN = @"^[^@\s]+@[^@\s]+\.[^@\s]+$";
  
                private readonly string _value;
  
                private Email(string value)
                {
                    if (string.IsNullOrWhiteSpace(value))
                    {
                        throw new ArgumentException("Email cannot be null or whitespace.", nameof(value));
                    }
  
                    if (!IsValidEmail(value))
                    {
                        throw new ArgumentException("Invalid email format.", nameof(value));
                    }
  
                    _value = value;
                }
  
                public static Result CanCreate(string value)
                {
                    if (string.IsNullOrWhiteSpace(value))
                    {
                        return Result.Failure("Email cannot be null or whitespace.");
                    }
  
                    if (!IsValidEmail(value))
                    {
                        return Result.Failure("Invalid email format.");
                    }
  
                    return Result.OK;
                }
  
                public Email():this(null) { }
  
                public static Email Create(string value)
                {
                    return new Email(value);
                }
  
                public override string ToString()
                {
                    return _value;
                }
  
                private static bool IsValidEmail(string email)
                {
                    return Regex.IsMatch(email, EMAIL_PATTERN);
                }
  
                public static implicit operator string(Email email)
                {
                    return email._value;
                }
  
                public static explicit operator Email(string email)
                {
                    return Create(email);
                }
            }
  

  That is quite an improvement as we introduced validating helper methods to tell whether the passed parameters are good to go. The validation result is reported in a Result object that encapsulates the outcome of a validation. The outcome must have error details in a non-empty string if validation fails. The logic only reaches the customer factory method only and only if all prior validation results represent success. We placed validation next to the constructor of Value Objects to show that they have the same guarding checks. However, validation could be placed somewhere else as it is strictly speaking a separate concern. There is no reason to not go DRY here though and make those guarding checks shareable for better maintainability and this is how our factory methods get to our rescue.

• If we extend the Result class with a property that can optionally return a value, we can reuse validation code in invariant checks.

•   public class Result
      {
          private readonly string _error;
  
          public string Error
          {
              get
              {
                  if (IsSuccess)
                      throw new InvalidOperationException("No error when success");
                  return _error;
              }
          }
  
          public bool IsSuccess => string.IsNullOrEmpty(_error);
  
          protected Result(string error)
          {
              _error = error;
          }
  
          public static Result<T> Success<T>(T value) => new Result<T>(value, null);
          public static Result Success() => new Result(null);
          public static Result<T> Failure<T>(string error) => new Result<T>(default, error);
          public static Result Failure(string error)
          {
              if (string.IsNullOrEmpty(error))
                  throw new ArgumentNullException(nameof(error));
  
              return new Result(error);
          }
  
          public override bool Equals(object obj)
          {
              if (obj is Result other)
              {
                  return IsSuccess == other.IsSuccess && _error == other._error;
              }
              return false;
          }
  
          public override int GetHashCode()
          {
              return HashCode.Combine(IsSuccess, _error);
          }
      }
  
    public class Result<T> : Result
      {
          private readonly T _value;
  
          public T Value
          {
              get
              {
                  if (!IsSuccess)
                      throw new InvalidOperationException("No value when there is an error");
                  return _value;
              }
          }
  
          protected internal Result(T value, string error) : base(error)
          {
              _value = value;
          }
  
          public override bool Equals(object obj)
          {
              if (obj is Result<T> other)
              {
                  return base.Equals(obj) && EqualityComparer<T>.Default.Equals(_value, other._value);
              }
              return false;
          }
  
          public override int GetHashCode()
          {
              return HashCode.Combine(base.GetHashCode(), _value);
          }
      }
  

  Value Objects

•     public record struct CustomerName
      {
          private const int MAX_NAME_LENGTH = 100;
          private const string NamePattern = @"^[A-Z][a-zA-Z]*$";
  
          public string FirstName { get; }
          public string LastName { get; }
  
          private CustomerName(string firstName, string lastName)
          {
              FirstName = firstName;
              LastName = lastName;
          }
  
          private static Result CanCreate(string firstName, string lastName)
          {
              if (string.IsNullOrWhiteSpace(firstName))
              {
                  return Result.Failure("First name cannot be null or whitespace.");
              }
  
              if (string.IsNullOrWhiteSpace(lastName))
              {
                  return Result.Failure("Last name cannot be null or whitespace.");
              }
  
              if (firstName.Length > MAX_NAME_LENGTH || lastName.Length > MAX_NAME_LENGTH)
              {
                  return Result.Failure($"First and last names cannot exceed {MAX_NAME_LENGTH} characters.");
              }
  
              if (!IsValidName(firstName) || !IsValidName(lastName))
              {
                  return Result.Failure("Names must contain only letters and start with a capital letter.");
              }
  
              return Result.Success();
          }
  
          //default 
          public CustomerName() : this(null, null) { }
  
          public static Result<CustomerName> Create(string firstName, string lastName)
          {
              var result = CanCreate(firstName, lastName);
              if (!result.IsSuccess)
              {
                  return Result.Failure<CustomerName>(result.Error);
              }
              return Result.Success(new CustomerName(firstName, lastName));
          }
  
          public override string ToString()
          {
              return $"{FirstName} {LastName}";
          }
  
          private static bool IsValidName(string name)
          {
              return Regex.IsMatch(name, NamePattern);
          }
  
          public static implicit operator string(CustomerName customerName)
          {
              return customerName.ToString();
          }
  
          public static explicit operator CustomerName(string fullName)
          {
              var names = fullName.Split(' ');
              if (names.Length != 2)
              {
                  throw new ArgumentException("Full name must contain exactly two parts: first name and last name.");
              }
              var result = Create(names[0], names[1]);
              if(!result.IsSuccess) { 
                  throw new ArgumentException(result.Error);
              }
  
              return result.Value;
          }
      }
  

•     public record struct Email
      {
          private const string EMAIL_PATTERN = @"^[^@\s]+@[^@\s]+\.[^@\s]+$";
  
          private readonly string _value;
  
          private Email(string value)
          {
              _value = value;
          }
  
          private static Result CanCreate(string value)
          {
              if (string.IsNullOrWhiteSpace(value))
              {
                  return Result.Failure("Email cannot be null or whitespace.");
              }
  
              if (!IsValidEmail(value))
              {
                  return Result.Failure("Invalid email format.");
              }
  
              return Result.Success();
          }
  
          public Email() : this(null) { }
  
          public static Result<Email> Create(string value)
          {
              var result = CanCreate(value);
              if(!result.IsSuccess)
              {
                  return Result.Failure<Email>(result.Error);
              }
  
              return Result.Success(new Email(value));
          }
  
          public override string ToString()
          {
              return _value;
          }
  
          private static bool IsValidEmail(string email)
          {
              return Regex.IsMatch(email, EMAIL_PATTERN);
          }
  
          public static implicit operator string(Email email)
          {
              return email._value;
          }
  
          public static explicit operator Email(string email)
          {
              var result = Create(email);
              if (!result.IsSuccess)
              {
                  throw new ArgumentException(result.Error);
              }
  
              return result.Value;
          }
      }
  

  Customer Entity and Application Service called from UI layer (it could be WPF view model, Razor view or MVC/WebApi Controller)

• 
      public class Customer
      {
          public CustomerID ID { get; }
          public CustomerName Name { get; }
          public USHomeAddress Address { get; }
          public Email Email { get; }
          public DateOfBirth DateOfBirth { get; }
          public AnnualIncome AnnualIncome { get; }
  
          private Customer(CustomerID id, CustomerName name, USHomeAddress address, Email email, DateOfBirth dateOfBirth, AnnualIncome annualIncome)
          {
              this.ID = id;
              this.Name = name;
              this.Address = address;
              this.Email = email;
              this.DateOfBirth = dateOfBirth;
              this.AnnualIncome = annualIncome;
          }
  
          private const uint MIN_AGE = 18;
          private const decimal MIN_INCOME = 80_000;
  
          public static Result<Customer> Create(CustomerID id, CustomerName name, USHomeAddress address, Email email, DateOfBirth dateOfBirth, DateTime currentDate, AnnualIncome annualIncome)
          {
              if (dateOfBirth.GetAge(currentDate) < MIN_AGE)
              {
                  return Result.Failure<Customer>($"Customer must be at least {MIN_AGE} years old.");
              }
              if (annualIncome.Value < MIN_INCOME)
              {
                  return Result.Failure<Customer>($"Annual gross income should be at least ${MIN_INCOME}$.");
              }
  
              return Result.Success<Customer>(new Customer(id, name, address, email, dateOfBirth, annualIncome));
          }
      }
  
      public class HomeInsuranceService
      {
          private readonly Database _database;
  
          public HomeInsuranceService(Database database)
          {
              _database = database ?? throw new ArgumentNullException(nameof(database));
          }
  
          //parameters are passed from UI
          public Result CreateCustomer(
              string firstName, string lastName,
              string street, string city, string state, string zip,
              string email,
              DateTime dateOfBirth,
              decimal annualIncome)
          {
              var customerId = CustomerID.NewCustomerID();
  
              var customerNameResult = CustomerName.Create(firstName, lastName);
              if (!customerNameResult.IsSuccess)
                  return customerNameResult;
  
              var customerEmailResult = Email.Create(email);
              if (!customerEmailResult.IsSuccess)
                  return customerEmailResult;
  
              var customerResult = Customer.Create(customerId, 
                      customerNameResult.Value, 
                      customerHomeAddressResult.Value, 
                      customerEmailResult.Value, 
                      customerDateOfBirthResult.Value, 
                      today, 
                      customerAnnualIncomeResult.Value);
              if (!customerResult.IsSuccess)
                  return customerResult;
              _database.SaveCustomer(customerResult.Value);
  
              return Result.Success();
          }
      }
  

• Now that this code does not repeat any checks and still has the rigidity or vigilance on invalid input but with the added convenience of validation. Now, the client code or a user will be better off figuring out how to pass valid data to your domain model. We were able to combine validation with checking invariants because we made our domain mode API more condensed. CanCreate methods were removed from public access and Factory extended the return value to Result object. That is pretty much in line with our original motto to provide a bare minimum of what consumer code or users can do with your core domain API. It is still worth stressing one more time that validation and invariant checks are different concerns and it is fine to keep them separate in the code base. Validation can do more sophisticated analysis of data, but oftentimes they are close enough so you can try to combine them in the Result pattern without compromising on DDD rules. This Result design pattern is implementation details and does not ruin primary aspects of observable behavior that should keep objects (value or entity) always valid through the sequence of calls.

• I would argue that in addition to the core validation in the Application Layer (i.e. in HomeInsuranceService), it may or even should be added on other architectural levels. The same set of rules can be also evaluated in the javascript code (client-side presentation layer) or be embedded in the WPF/Razor UI controls. These supplemental validations are not meant to replace the core validation and should not be considered as duplicated code. Those layers are designed to enhance users’ experience by giving feedback faster and using more engaging communication. Sometimes technologies such as ASP.NET have gimmicks to share validation code (using various pre-built validator components) but generally, that is not shareable and you don’t need to push for being DRY here. However, some sensible shareable bits would be beneficial. You can reuse a regex expression constants and bind it through code behind or binding expression. Whatever is practical is fine but generally not required.

• By looking at the above implementation you can see a “smell” in validation. Formatting or providing the error message is not one of its designated concerns. The message belongs to the Presentation Layer as it knows exactly how to display, format, and present an error message or notification. The application can support multiple languages after all and our domain layer should be language-agnostic in that sense. I will show how this aspect is addressed in “clean” Validation in the next article.

abstract class Entity<TId> where TId : IEquatable<TId>
{
    public TId ID { get; }

    public Entity<TId>(TId id)
    {
        Id = id;
    }
}

public class Customer : Entity<TId>
{
    public CustomerName Name { get; }
    public USHomeAddress Address { get; }
    public Email Email { get; }
    public DateOfBirth DateOfBirth { get; }
    public AnnualIncome AnnualIncome { get; }

    private Customer(CustomerID id, CustomerName name, USHomeAddress address, Email email, DateOfBirth dateOfBirth, AnnualIncome annualIncome) : 
        base(id)
    {
        this.Name = name;
        this.Address = address;
        this.Email = email;
        this.DateOfBirth = dateOfBirth;
        this.AnnualIncome = annualIncome; 
    }

    private const uint MIN_AGE = 18;
    private const decimal MIN_INCOME = 80_000;

    public static Customer Create(CustomerID id, CustomerName name, USHomeAddress address, Email email, DateOfBirth dateOfBirth, AnnualIncome annualIncome, DateTime currentDate)
    {
        if (dateOfBirth.GetAge(currentDate) < MIN_AGE )
        {
            throw new ArgumentException($"Customer must be at least {MIN_AGE} years old.", nameof(dateOfBirth));
        }
        if(annualIncome.Value < MIN_INCOME)
        {
            throw new ArgumentException($"Annual gross income should be at least ${MIN_INCOME}$.", nameof(annualIncome));
        }

        return new Customer(id, name, address, email, dateOfBirth, annualIncome);
    }
}

public record struct AnnualIncome
{
    private const decimal MinIncome = 100;
    private const decimal MaxIncome = 100_000_000;

    public decimal Value { get; }

    public AnnualIncome() : this(decimal.Zero) { }

    private AnnualIncome(decimal value)
    {
        if (value < MinIncome || value > MaxIncome)
        {
            throw new ArgumentException($"Annual income must be between {MinIncome}$ and {MaxIncome}$.", nameof(value));
        }

        Value = value;
    }

    public static AnnualIncome Create(decimal value)
    {
        return new AnnualIncome(value);
    }

    public override string ToString()
    {
        return Value.ToString("C"); // Format as currency
    }

    public static implicit operator decimal(AnnualIncome annualIncome)
    {
        return annualIncome.Value;
    }

    public static explicit operator AnnualIncome(decimal value)
    {
        return Create(value);
    }
}

Notice how the Entity differs from the Value Object. It possesses an identity represented by some ID that is a characteristic that does not change throughout the entity's life, whether it mutates or not. We stressed that fact in our domain model by introducing an Entity base class. Entities can be tracked and referenced by their IDs from other entities. That is also why the ID should be equitable to at least say whether IDs represent the same entity object or not.

Entity also strengthens generic weaker invariants of Value Object by putting additional constraints on top of them. The goal here is to be as profuse with constraints as possible. More constraints lead to less uncertainty and more robust code. The more limiting concepts you bring from the real-world domain into the code, the less opportunity you leave for misinterpretation or malfunction.

The same rule applies here that the coder domain model should be pure, i.e. technology agnostic, without side effects or external dependencies such as logging, system clock, emails, databases, network calls, IO system, communication bus, benchmarks, alerts, frameworks, etc. Prefer packing all the sensible invariants into immutable Value Objects and doing all the state transitioning in Entities. Follow a functional style of programming wherever possible and make your methods honest. I will elaborate on those topics a bit later.

The point of the domain model layer is to give you absolute freedom from the technical aspect of your programming language and executing environment so you can remain unbiased and focused solely on domain knowledge and the “offline” business you are creating your solution for. The more logic you can squeeze into that layer the better as you automatically increase the level of control over your code. That code is highly testable, debuggable, readable, and easy to work because accidental complexity is at a minimum here.

You might yell, hmm, how in the hell I am going to be efficient technically so that the domain model runs fast on modern hardware, and provides runtime transparency by leveraging logging, telemetry, health checks, heart beats? You want async/await, multi-threading, structured logging, service bus, serialization, security/authorization management, storage, communication, and so on. The quick answer those concerns have no place in the domain model and generally get offset to the outer boundaries of the system but that does not mean that the domain model should be completely ignorant of those pure technical use cases. Yes, you should not embed the features above in the declaration of your entities or value objects because those features don’t have real-life double or analog in a real domain. Still, you can provide technology-agnostic hookups that can be leveraged in those technical scenarios.

Yes, domain logic should be synchronous and thread-unsafe, i.e. free of any multithreading or asynchronous/delayed processing/synchronization but it can be implemented granular enough for parallelism orchestrated by the application layer. Yes, we don’t add explicit loggers or telemetry publishers but we provide domain events that can be intercepted and logged on upper layers so we can understand what is going on in the domain layer. Yes, we don’t have methods in entities to save or get them from a database but we have application services “repositories” to do so efficiently. Many more things are not allowed in the core domain to keep it clean, fast, reliable, and easy to work with but in reality, it is not limiting you in your technology stack. You will still be able to add nicely all the other aspects and concerns but do it in a specific way so you don’t compromise the purity of the domain model with extrenious code.

If the core domain, i.e. the heart of the system is designed right you should be able to observe and track the harmony of the code modeling it. When the code is written correctly following the rules I am going to be talking about here you should feel immediate satisfaction, fulfillment, and confidence in the reliability of your work. If you feel the opposite, i.e. something smells or gut feeling puts you in slight discomfort, that is a sign you are missing something your frame is shaky and you can’t build a reliable structure on top of it. The appreciation of symmetry is in our nature. I would argue that we are born with it. Every symmetry is perceived as beautiful by our mind and the beauty represents the most stable constructions in the universe. Look at all those natural biological ornaments, fractals, spirals, Fibonacci sequences, or golden ratios. Those are the bricks of perfection and the more such bricks you incorporate into your software solution, the more adequate and robust it should be.

The canonical domain model should look like a hierarchy of objects where limitations/invariants are added from the leaf to the root layer. The root is usually represented by an entity that is called an aggregate root in domain-driven design. The aggregate is the smallest group of interconnected entities maintaining transactional consistency. The invariants in the aggregate are held at all times and changes are applied atomically over all objects included in that aggregate. The hierarchy (“tree“ like) is a very convenient structure well understood by our mind as it finds manifestation in almost every object in nature that is why it is beneficial to stick to the “tree” hierarchy in the domain model.

Also, psychologists say we can’t operate with more than 7 objects in our memory at a time so I take that number as a rule of thumb when designing a system. Every modeled concept should not consist of more than 7 constituents. Methods should not do more than 7 decision making, entities/value objects should not contain more than 7 properties, given aggregate (group of objects bound by certain rules or limitations) should be comprised of more than 7 of other constituents, a context (“bounded context“ in DDD terms) should not contain more than 7 aggregates.

I will expand on the concepts that did not find detailed review in this article later. For now, I would like to linger on a very important aspect of software design which is Validation. I will talk about validation in the next article and show where it belongs in relation to the core domain.

We can’t avoid primitive types, as they are the building blocks of our code, but we need to tame them to our needs by rigorously controlling them in Value Objects.

Let’s write code for the value objects from the previous article by starting with the simplest one

public readonly struct CustomerID
{
    public static CustomerID Empty() => new CustomerID(0);
    public static CustomerID NewCustomerID() => new CustomerID((uint)IdGenerator.GetNextId());

    //it can be Guid, string, or any other type chosen based
    //on performance and convenience requirements
    public readonly uint Value;

    private CustomerID(uint value)
    {
        Value = value;
    }

    public override bool Equals(object obj)
    {
        return obj is CustomerID iD && Equals(iD);
    }

    public bool Equals(CustomerID other)
    {
        return Value == other.Value;
    }

    public override int GetHashCode()
    {
        return Value.GetHashCode();
    }

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

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

//Guid has the most convenient built-in generator but it may not be performant enough
//on the storage side
internal static class IdGenerator
{
    private static long _currentId = 0;

    // called at application startup using some seeding strategy
    internal static void SetIdGenerator(long seed)
    {
        _currentId = seed;
    }

    internal static long GetNextId()
    {
        return Interlocked.Increment(ref _currentId);
    }
}

Value Objects are typically immutable as they are identified by the values they hold, rather than by some identity or reference in memory. So if you need it to mutate, you just create a new Value Object with changed values replacing the old one. Thus you simplify the code (see previous article for details) and avoid many other potential problems with Value Objects when sharing them or using them in multi-threaded applications. That is why the concept of equality is very important here as it defines how instances of these objects are compared and identified. Since they don’t have an identity, equality is the only way to tell whether two objects represent the same characteristic and that is often handy in all kinds of reconciliation and lookup in the application logic. That makes Value Objects a good choice for sorting, filtering, and finding. C# also encourages to implementation of GetHashCode whenever we implement equality and that makes them great for Dictionary keys or HashSets. Now CustomerId can be easily used for Customer lookup by its ID.

All that equality plumbing can be easily collapsed into a few lines of code with the newer C# syntax. We don’t add any additional invariants as the unit type already represents the intent to store the ID as a positive number.

    public record struct CustomerID(uint Value)
    {
        public static CustomerID Empty() => new CustomerID(0);
        public static CustomerID NewCustomerID() => new CustomerID((uint)IdGenerator.GetNextId());

        // we can still add more code to make specialized constructor private
    }

I digressed though and let’s move on to the Email where we have a bit more handmade constraints.

public record struct Email
{
    private const string EMAIL_PATTERN = @"^[^@\s]+@[^@\s]+\.[^@\s]+$";

    private readonly string _value;

    private Email(string value)
    {
        if (string.IsNullOrWhiteSpace(value))
        {
            throw new ArgumentException("Email cannot be null or whitespace.", nameof(value));
        }

        if (!IsValidEmail(value))
        {
            throw new ArgumentException("Invalid email format.", nameof(value));
        }

        _value = value;
    }

    //prohibiting default constructor
    public Email():this(null) { }

    //that is the only entry point to create instance
    public static Email Create(string value)
    {
        return new Email(value);
    }

    public override string ToString()
    {
        return _value;
    }

    private static bool IsValidEmail(string email)
    {
        return Regex.IsMatch(email, EMAIL_PATTERN);
    }

    //adds more incapsulation rather than exposing Value property of string type
    public static implicit operator string(Email email)
    {
        return email._value;
    }

    public static explicit operator Email(string email)
    {
        return Create(email);
    }
}

You see how impossible it is to use a random string as an email now. When writing code for a core domain, design your objects in a way that is impossible to misuse by throwing blunt exceptions on unexpected input or creating always valid specialized types that control the correctness of your code at compilation time. Most of the relevant “clean code” principles are met automatically. We follow DRY (we don’t repeat email validation logic as we can use Email type in other Entities), SOLID (validation is put in one place, and one can inherit from Email to create more specialized versions of them such as a company or personal email, the email record can be used in sorting, filtering, lookups, etc.), KISS (it looks simple, clear, and readable), Fail Fast (it fails right at the boundary of instantiation right in the constructor), YAGNI (it is even lacking Value property as it is not defined in ubiquitous language, i.e. project requirements handed in by domain experts). Also, the object is immutable, which avoids sharing and handling issues in multi-threaded environments.

Here is “CustomerName” Value Object with even more constraints to its attributes

public record struct CustomerName
{
    private const int MAX_NAME_LENGTH = 100;
    private const string NamePattern = @"^[A-Z][a-zA-Z]*$";

    public string FirstName { get; }
    public string LastName { get; }

    private CustomerName(string firstName, string lastName)
    {
        if (string.IsNullOrWhiteSpace(firstName))
        {
            throw new ArgumentException("First name cannot be null or whitespace.", nameof(firstName));
        }

        if (string.IsNullOrWhiteSpace(lastName))
        {
            throw new ArgumentException("Last name cannot be null or whitespace.", nameof(lastName));
        }

        if (firstName.Length > MAX_NAME_LENGTH || lastName.Length > MAX_NAME_LENGTH)
        {
            throw new ArgumentException($"First and last names cannot exceed {MaxLength} characters.");
        }

        if (!IsValidName(firstName) || !IsValidName(lastName))
        {
            throw new ArgumentException("Names must contain only letters and start with a capital letter.");
        }

        FirstName = firstName;
        LastName = lastName;
    }

    //default 
    public CustomerName():this(null, null) { }

    public static CustomerName Create(string firstName, string lastName)
    {
        return new CustomerName(firstName, lastName);
    }

    public override string ToString()
    {
        return $"{FirstName} {LastName}";
    }

    private static bool IsValidName(string name)
    {
        return Regex.IsMatch(name, NamePattern);
    }

    public static implicit operator string(CustomerName customerName)
    {
        return customerName.ToString();
    }

    //adding a shortcut to create name from a single string
    public static explicit operator CustomerName(string fullName)
    {
        var names = fullName.Split(' ');
        if (names.Length != 2)
        {
            throw new ArgumentException("Full name must contain exactly two parts: first name and last name.");
        }
        return Create(names[0], names[1]);
    }
}

It incorporates quite a few restrictions that might not be obvious till you start thinking of all the possible ways the object can be abused by client code. Domain experts may not be that detailed to tell that they need a cap on string length or that the system should not allow special characters in the names but that is your job as a developer to think through all those patterns leading to the combinatorial explosion of invalid or abusive states. You can also check with your stakeholders about all those additional restrictions and limitations and they will tell with 99% certainty that it is a great idea. Never fear to overdo that. It is better to weaken your grip later and remove a couple of constraints (exception throws) than debugging through issues or dealing with malicious hacker attacks exploiting oversites in your model.

Let’s move on to the home address of a customer. We know that at least in the first versions of our system it will be a US address. Let’s code for that and put as many limitations as we could possibly think of.

public record struct USHomeAddress
{
    private const int MaxStreetLength = 100;
    private const int MaxCityLength = 50;
    private const int MaxStateLength = 2;
    private const int MaxZipCodeLength = 10;

    private const string StreetPattern = @"^[a-zA-Z0-9\s,'-]*$";
    private const string CityPattern = @"^[a-zA-Z\s,'-]*$";
    private const string StatePattern = @"^[A-Z]{2}$";
    private const string ZipCodePattern = @"^\d{5}(-\d{4})?$";

    public string Street { get; }
    public string City { get; }
    public string State { get; }
    public string ZipCode { get; }

    private USHomeAddress(string street, string city, string state, string zipCode)
    {
        if (string.IsNullOrWhiteSpace(street))
        {
            throw new ArgumentException("Street cannot be null or whitespace.", nameof(street));
        }

        if (string.IsNullOrWhiteSpace(city))
        {
            throw new ArgumentException("City cannot be null or whitespace.", nameof(city));
        }

        if (string.IsNullOrWhiteSpace(state))
        {
            throw new ArgumentException("State cannot be null or whitespace.", nameof(state));
        }

        if (string.IsNullOrWhiteSpace(zipCode))
        {
            throw new ArgumentException("ZipCode cannot be null or whitespace.", nameof(zipCode));
        }

        if (street.Length > MaxStreetLength || city.Length > MaxCityLength ||
            state.Length > MaxStateLength || zipCode.Length > MaxZipCodeLength)
        {
            throw new ArgumentException("Address components exceed maximum length.");
        }

        if (!IsValidComponent(street, StreetPattern) || !IsValidComponent(city, CityPattern) ||
            !IsValidComponent(state, StatePattern) || !IsValidComponent(zipCode, ZipCodePattern))
        {
            throw new ArgumentException("Invalid address format.");
        }

        Street = street;
        City = city;
        State = state;
        ZipCode = zipCode;
    }

    public static USHomeAddress Create(string street, string city, string state, string zipCode)
    {
        return new USHomeAddress(street, city, state, zipCode);
    }

    public override string ToString()
    {
        return $"{Street}, {City}, {State} {ZipCode}";
    }

    private static bool IsValidComponent(string component, string pattern)
    {
        return Regex.IsMatch(component, pattern);
    }

    public static implicit operator string(USHomeAddress homeAddress)
    {
        return homeAddress.ToString();
    }

    public static explicit operator HomeAddress(string address)
    {
        var parts = address.Split(',');
        if (parts.Length < 3)
        {
            throw new ArgumentException("Address must contain at least street, city, and state.");
        }

        var street = parts[0].Trim();
        var city = parts[1].Trim();
        var stateZip = parts[2].Trim().Split(' ');

        if (stateZip.Length != 2)
        {
            throw new ArgumentException("Address must contain a valid state and zip code.");
        }

        var state = stateZip[0].Trim();
        var zipCode = stateZip[1].Trim();

        return Create(street, city, state, zipCode);
    }
}

Do you see how bloated the Customer entity would be if we put all those validation rules there? The example is still contrived as there is always much more than you can regulate or add here to represent real-life use cases.

Next and the last one is DateOfBirth

public record struct DateOfBirth
{
    private const int MinAge = 1;
    private const int MaxAge = 150;

    public DateTime Value { get; }

    //default should throw exception
    public DateOfBirth():this(DateTime.MinValue, DateTime.MinValue) { }

    private DateOfBirth(DateTime value, DateTime currentDate)
    {
        if (value == DateTime.MinValue)
        {
            throw new ArgumentException("Date of birth cannot be the minimum date value.", nameof(value));
        }

        var age = CalculateAge(value, currentDate);
        if (age < MinAge || age > MaxAge)
        {
            throw new ArgumentException($"Age must be between {MinAge} and {MaxAge} years old.", nameof(value));
        }

        Value = value;
    }

    public static DateOfBirth Create(DateTime value, DateTime currentDate)
    {
        return new DateOfBirth(value, currentDate.Date);
    }

    public override string ToString()
    {
        return Value.ToString("yyyy-MM-dd");
    }

    public uint GetAge(DateTime currentDate) => CalculateAge(Value, currentDate);

    private static int CalculateAge(DateTime dateOfBirth, DateTime currentDate)
    {
        var age = currentDate.Year - dateOfBirth.Year;
        if (dateOfBirth.Date > currentDate.AddYears(-age)) age--;
        return age;
    }
}

This code ensures not only the correctness of the date but also that it belongs to a person/customer who is allowed to interact with the system. Please make a note that it does not call DateTime.Today or DateTime.Now that would make the implementation “impure” in a functional sense since it would have implicit “external“ dependency on the system clock and that is something to avoid. Not only does it make the unit test harder but also leads to unpredictable output as it changes over time and I don’t even mention all those complications with time zones.

That completes the list of Value Objects and I will get back to the Customer Entity in the next article.

Let’s pick up a domain. I chose specifically the one I have never worked in such as Insurance Management System. You are tasked with a system maintaining the business processes of an insurance company working with real estate. We will deal with hundreds of requirements but let’s start with the easiest ones such as customer registration. That simple act of registration usually includes many rules and requirements but I will list a few basic ones.

• The customer should have a unique ID generated by the System that can be used to reference this customer in the URL or do a lookup when a support agent is trying to pull the customer’s record. There are some requirements for that ID. It is a string with a length of 10 that contains alphanumeric characters.

• The customer should also have a valid email, First and Last Name, and Date of Birth

• We can pick a dozen other attributes for instance Primary Address, Insured Property Address, Employer, Salary, etc but we will keep it simple for now.

The Naive approach following OOP is to create a Customer with read-only properties and a constructor like below.

public class Customer
{
    public string ID { get; }
    public string FirstName { get; }
    public string LastName { get;  }
    public string Address { get;  }
    public string Email { get; }
    public DateTime DateOfBirth { get; }


    const uint REASONABLE_MAX_AGE = 120;
    const float AVERAGE_DAYS_IN_A_YEAR = 365.2425f;
    public Customer(string id, string firstName, string lastName, string address, string email, DateTime dateOfBirth)
    {
        this.ID = id ?? throw new ArgumentNullException(nameof(id));
        this.FirstName = firstName ?? throw new ArgumentNullException(nameof(firstName));
        this.LastName = lastName ?? throw new ArgumentNullException(nameof(lastName));
        this.Address = address ?? throw new ArgumentNullException(nameof(address));
        this.Email = email ?? throw new ArgumentNullException(nameof(email));

        var years = (DateTime.Now - dateOfBirth).TotalDays / AVERAGE_DAYS_IN_A_YEAR;
        if(years<0 || years> REASONABLE_MAX_AGE)
        {
            throw new ArgumentException("Age is not reasonable");
        }

        this.DateOfBirth = dateOfBirth;
    }
}

OOP is happy as the state is encapsulated, and the constructor gives some protection against invalid input. You cannot create an empty Customer or a customer without any of the required fields. But this is exactly where the snowball of possible issues emerges.

A good domain model would allow for interaction with a client in a legit way and prohibit any possible deviation from the modeled restrictions (aka invariants). What can we do here?

var weirdValidCustomer = new Customer(
    "!special symbol not allowed",
    "  start with empty characters?",
    "32 last name starts with a number",
    "Is PO Box OK?",
    "---I don't have one--",
    DateTime.Today.AddYears(30).Add(TimeSpan.FromMinutes(20)));// we know the time of birth?

You can bog down such a system by passing a string from the full content of “War and Peace” by Tolstoy. Millions of invalid inputs and their combinations can be passed resulting in a combinatorial explosion of possible buggy states.

Light restrictions cause enormous possibilities for exploitation (by hackers), confusion, or wasted debugging hours. Entropy starts thriving in such conditions inevitably leading to code degradation and chaos.

What you should do is not go to another extreme and start adding a huge number of checks to the customer constructor. But that would still be better than not having any checks. Rather think of yourself as a sculptor, focus on one thing at a time, and cut all undefined, unnecessary, irrelevant. Do it piece by piece, step by step until you face a wall of the underlying requirements that you can’t go any further.

Being a sculptor when modeling the domain means creating new abstractions and delegating all the logic restricting our states (i.e. reducing our entropy) to those abstractions till you are left with very few states just necessary to implement the given use cases from a spec.

The reality is that the subset of valid unique IDs is much smaller when a manifold of all strings. The same goes for strings, names, and emails where the number of good instances of those strings is incomparably less than the number of all the strings the string type allows for. We need an abstraction expressing those valid subsets. We can create and name them accordingly without even going deeper into how they should properly function. We will get to them later when we zoom in our focus on them.

It is so easy just to create new classes where we pretend all rules are already enforced and this is a very efficient move to remove all uncertainty and proliferation of possible invalid states. Here we create new classes CustomerId, CustomerName, Address, Email, and DateOfBirth with all needed to maintain their invariants, i.e. rules defined by the spec explicitly or implicitly. The customer has very little left to enforce rules in its internal constituents. It does nothing but ensure all the required constituents are supplied. That makes it very robust and leaves no opportunity for incorrect instantiation of a Customer object.

    public class CustomerId {…}
    public class CustomerName {…}
    public class HomeAddress {…}
    public class Email {…}
    public class DateOfBirth {…}

    public class Customer
    {
        public CustomerID ID { get; }
        public CustomerName Name { get; }
        public HomeAddress Address { get;  }
        public Email Email { get; }
        public DateOfBirth DateOfBirth { get; }

        public Customer(CustomerID id, CustomerName name, Address address, Email email, DateOfBirth dateOfBirth)
        {
            this.ID = id ?? throw new ArgumentNullException(nameof(id));
            this.Name = name ?? throw new ArgumentNullException(nameof(name));
            this.Address = address ?? throw new ArgumentNullException(nameof(address));
            this.Email = email ?? throw new ArgumentNullException(nameof(email));
            this.DateOfBirth = dateOfBirth ?? throw new ArgumentNullException(nameof(email));
        }
    }

Our code became simpler, much simpler and it eliminates many more invalid states than the first version. It is just verifying the fact that the parameter is supplied and it knows if it is supplied it cannot be in an invalid state. That technique combats a well-known antipattern known as Primitive Obsession where Domain classes use language primitive types (string, int, DateTime, float, etc.) rather than specialized types representing Domain concepts and that makes it hard for domain objects to ensure the correctness of its parts at all times. Think of it. If you use email or address as properties in quite a few classes you will have to re-run the same guarding checks over and over. It violates the DRY (don’t repeat yourself) rule. Even if you extract the guarding logic and put it in helper methods, it would still be easy to make a mistake. If you assign a primitive type value to the properties in many places it is just a matter of time when you forget to use the helper method to confirm validity.

Specialized types build that fortress around your preserved state that makes your model always valid. There is one characteristic of such types that simplifies their implementation and utilization. That is immutability. If specialized type states never change from their creation, we can put all the heavy guarding logic in their constructor. There won’t be any other manipulators or methods in them as they are immutable by definition. If we need a change in their state, we just create a new object with the same constructor and swap the old object with the new one.

Such types are called “value objects” because they are defined by nothing but their values and they don’t have an identity (unique features outside of the set of values of their properties). You can replace one “value object” with another as long as it the have same values in their data frames.

One way of modeling value objects is to C# structs as they have some intrinsic properties of value objects. Structs are passed by value, they are compared by internal state by default. You won’t get NRE (NullReferenceException) using them so you don’t need that guarding check for Null. But the drawback is that the struct always has a parameterless constructor so you can always create a zero object and if it is not part of a valid subset, you will have to burden the caller with additional code checking against using zero value. I would prefer using a class if there is no performance penalty here or if I have the luxury of using .net core, “record” would be a better option to model value objects.

You will see all the wires are dangling and electric elements sticking out. It is not meant to be exposed to the external world without protection. The whole idea is to minimize any deviation from a predefined and preferably single way to operate. If the rules are violated by you pulling the wires, submerging the car into the water, or applying power to the wrong terminal, the circuit should detect and fail fast with fuses going off. It should break and stop the entire mechanism from going into undocumented conditions. Thus it does not cause damage, hurt, or burn anyone. The cost of a chain of errors is high so it is cheaper to self-destruct. That pretty much applies to software as we model reality.

What if we don’t fail fast in the core domain and allow invalid arguments in a method performing business operations? The consequences are vast and violating business requirements could be the less serious problem. If methods preconditions or object invariants are not properly checked, any bug or malicious call exploiting this deficiency can corrupt or compromise the database, send unplanned emails, shut down production processes, or exhaust server resources. The core domain has no right to fall short of maintaining its invariants and checking methods pre and post-conditions. And it is the only thing it should do, i.e., defend against unauthorized use.

With all that the domain entities are complex enough and it is unfair to ask them for anything else. It should do the most straightforward thing: to fail hard throwing brief info of what is violated and not offer a second chance for corrected input. Like a sculptor making a statue cuts off all unnecessary parts, so does the developer create the domain model (the heart of the system) by limiting all possible states and interactions with users or other systems according to the agreed requirements from stakeholders. That is the best way to tame accidental complexity.

But how to protect our modeled domain from invalid input in a client-friendly way so that the system does not escalate and throw things at you on any hiccup? Clients would be reluctant to play that shooter game and start from the beginning on the first shot. Meet the validation. It is that toy cover or a shield protecting our work from unintended interaction nicely so our device does not blow up on the first mistake. The point is it is not part of the core domain that just throws straightforward errors. The validation allows any input, tries to make sense of it, and decides whether to allow it through or do something else but not throw exceptions or terminate the process. It has many graceful options such as showing a nice message on how to remediate, highlighting your typing in a text box, redirecting you to support chat, or anything else appealing from a usability perspective.

Validation is typically sitting in the Application layer as part of the application facade defending internals from risky interactions. The core domain can be a helper here though. It can provide shared helper methods to check certain conditions in a “functional“ way (i.e. without creating or maintaining a state) or allow for a “specification” pattern. The latter is quite popular as it allows to reuse of many domain checks in a structured way. That generally helps be DRY. The checks are the same but reactions to the errors are different. Domain model immediately throws while validation assumes bad input and tries to suggest a workaround.

Still, I think that is enough for the article and I will toss some examples in the next one.

Unexperienced developers may start feeling that monster in the room without fully recognizing it. They are given a seemingly easy task in the beginning that sounds simple but all of a sudden something gets in their way and deters from their direct responsibility to write code. They are already feeling the breath of that monster but they don’t know what that is. They initially gave optimistic promises and ETAs and now what? They just can’t deliver because they are facing a wall, and that wall has a name. Meet “accidental complexity” which is an added complexity of the original problem and it stems from all the tools, programming languages, and techniques we are using to model a solution in software. The domain itself is usually complex enough and it features “essential complexity”. Stakeholders summon us IT guys to help because their complexity can’t fit one head (or their team heads) anymore. They delegate all that complexity to us and we truly need to re-delegate that to software nicely otherwise we and our support team become an easy target for frustrated customers. To be effective developers need to know how to tame accidental complexity in their stack so that they have more time to work on more relevant tasks. Ideally, they should spend more time on clarifying problem domain requirements, and nuances, and how to model them adequately with programming language bricks as this is where the value is. Corporate stakeholders focus on real business goals and decisions and they don’t care how your project is organized, how much technical debt it obtained, what language you used, whether you rely on a garbage collector, and so on. You are to manage all that risk to be successful and there are ways and approaches to do that.

The software serves a particular purpose and every piece of it is the source of so-called entropy and combinatorial explosion. What is entropy? It is the natural tendency of a system to degrade or transition from an organized structure into a chaotic matter if there is no constant effort to get the order back. The same is happening with software design. Code entropy is the gradual degradation of code quality over time. Every code is subject to it and eventually becomes increasingly complex, hard to understand, and more prone to errors. That stems from rushed patchy development, unclear contradicting requirements, technical debt accumulating, and a lack of consistent refactoring. Eventually, it leads to project delays, increased costs, and failures. Software becomes so fragile that it operates predominately in undocumented and unforeseen states and code paths producing noisy outputs, crashing, throwing errors, causing data corruption, and many other undesirable outcomes.

Another enemy is the combinatorial explosion. It inevitably leads us to an explosion of edge cases that practically can’t be 100% covered with automated tests. For each new parameter, input field, or feature, the number of potential interactions and code paths grows exponentially, not linearly. Testing every possible combination becomes practically unachievable, especially as the application scales. With the growth of variables, states, and lines of code, some combinations of them are never foreseen by the developer and often manifest as bugs. They are particularly troublesome because they don’t show up during typical testing environments but can emerge in production under narrow conditions, causing reliability issues and complicating debugging.

The ideal situation is when a function or an action is served without a single line of code. It is useful to consider whether there is a good reason to go with software in the first place. Maybe there are alternative ways to solve a problem efficiently without coding. Many “no code” tools can be the way to proceed. Like in martial arts, the best way to win a battle is to avoid it. Try to solve the problem without software, but if the software is unavoidable, you have to strike first, and here are the martial arts to win this battle.

If we need software, you have to be sure your solution is minimal and simple enough for the given requirements. I would even consider whether having just one button is good enough. Because if you add a text box or any additional input, you have to start considering entropy and the explosion of internal states.

The most common techniques for me to combat all those issues are Object Oriented Programming (OOP) coupled with Domain Driven Design (DDD) and the “Fail Fast” principle. Why, because they are at the heart of fighting complexity, reducing possible states, good code quality, and readability. Of course, other principles of “clean“ code still apply but the two above are simple and effective weapons against complexity.

It is very important to employ those principles on day one to avoid facing the consequences of accidental complexity. You should fight it with all your force and power. Of course, they are huge topics by themselves, but I will cover them piece by piece in practical examples. Here are some excerpts.

• Start with your domain model first

• don’t think about logging, monitoring, performance, garbage collection, exception handling, or interacting with databases, emails, or external systems. You will get back to all that later when your domain model is satisfactorily mature.

• Don’t let bad input at all cost. Check every public method parameter fiercely and throw and throw exceptions if their values are not from the expected range allowing only a single happy path.

• Remove all possible methods and code paths that are not executed through declared requirements. We are not writing a flexible library here for numerous use cases.

• Try to make all the method parameters (including return values) domain objects.

• Throw errors mercilessly on every unclear or undocumented condition. Never try to fix, or implement a workaround for invalid input in core domain level. That is not happening here. Every step left or right off the trail causes harsh exceptions thrown from the core domain realm.

• You should never allow any further execution at first traces of something going south. Don’t think about the client and how bad it would feel to crash. It is not your business here.

• All properties should be part of the domain. No nulls or semi-valid objects are tolerated.

• Use test-driven approach writing test first to overcome paralysis to start coding

• Use no external or out-of-process impure dependencies in your core domain. Everything should be written there as if all objects are available in fast memory.

Rejoice in your core domain. You are the king there. Only in the core domain, do you have the luxury to fully fight essential complexity and not to deal with accidental complexity, and combat entropy with maximum chances to win. That is why you need to push as much code as possible in there and push a very thin layer to the boundary of your application where all the orchestration and integration with external actors takes place. You have all the tactical tools at your disposal to organize your domain following the golden standards of efficiency and minimalism. This is where you think of OOP, SOLID, singletons, visitors, factories, and so on.

Unlike the core domain, you are limited in all other layers.

• Utility methods should be flexible to tolerate garbage input

• The validation layer shouldn’t throw but rather inform about problems and not use exception throwing at all.

• Logging should allow a gazillion parameters to log every possible combination of parameters of various types. Otherwise, the tool won’t be convenient.

• You don’t create a diagram of classes to read/write from/to a file or a database.

• Your view models or controllers should look more like a transaction script orchestrating and stitching everything else together.

Automated testing with DDD is bliss as you can achieve 100% coverage here without engaging test doubles, mocks, or spies as the core domain does not need much reliance on external dependencies.

Practicing those recommendations is doing a huge favor to your future self and everyone taking ownership of the code after you. You will see that following just a few primary principles from above lets you build software fast and almost flawlessly from day one.

Let’s consider a more or less realistic use case. Say you are developing a hotel booking system and you get the most basic requirement first. You need to implement a feature to register as a customer.

See the code in the next blog.

Stay connected!

These are all good for theorizing, training your intelligence, passing exams, and showing off with coworkers. However, the usefulness of that knowledge is pretty limited when it comes to small or medium-sized projects with a couple of devs. The enterprise world is a much better fit for all those architectural guidelines. And to be honest it is hard to reconcile them even there as they often advise following contradicting approaches, leading to unavoidable analysis paralyses or poor code. Code that is hard to work with, to say the least. That becomes so confusing that even experienced senior developers get puzzled and make suboptimal decisions.

All those thick classical books and articles still leave simple daily questions unanswered. Here are some that sound pretty naïve.

• Where to do the validation? Is that in this class or the one that contains it? How should we react to the result of validation? Should we throw or return a success flag with an error message? What about Debug.Assert checks? Should we repeat similar validation on every level of a call stack or use DRY and put it in the lower-level method?

• Should we intercept exceptions, where, and how?

• Is it ok to create an object that is not valid till we call a couple of initializing methods or set a couple of properties?

• Do we check all or some method parameters? How should we react to invalid parameters? Should we try to fix invalid input or throw an exception? Should the exception contain as many details as it can, or just give a brief and broad description? Where do we catch exceptions?

• Is it ok to copy and paste logic if it is similar but different or should we always go DRY?

• How many lines are ok to be in a method?

• Can we return null here or there or should we never return null and rather use a null object pattern?

• There are multiple ways to organize a diagram of classes for a given problem. What diagram is better? How to organize a solution in Visual Studio?

I am not going to say that I have a single answer to these questions as the real answer is "it depends". But I come to writing code from a different angle and that lets me answer those questions naturally. That angle is a manifestation of broader ideas related to harmony, entropy, stability, probability, degree of freedom, human perception, and philosophy that are the essence of many interesting productivity metrics in code and even in your life.

Stay tuned!