Implementing a domain service with DDD in C#

user_1211879 0
Viewed 99

I'm working on a domain model writing my software all DDD and stuff doing a great job, when I suddenly bump into the same problem I have been facing over and over again and now it's time to share some insights. The root of the problem lies in the uniqueness of data.

For example, let's say we're writing this awesome domain model for a user. Obviously the username is unique and just to be as flexible as possible we want the user to be able to change his name, so I implemented the following method:

public void SetUsername(string value)
{
    if (string.IsNullOrWhiteSpace(value))
    {
        throw new UserException(UserErrorCode.UsernameNullOrEmpty,
            "The username cannot be null or empty");
    }
    if (!Regex.IsMatch(value, RegularExpressions.Username))
    {
        throw new UserException(UserErrorCode.InvalidUsername,
            "The username {value} does not meet the required ");
    }
    if (!Equals(Username, value))
    {
        Username = value;
        SetState(TrackingState.Modified);
    }
}

Again, this is all fine and fancy, but this function lacks the ability to check if the username is unique or not. So writing all these nice articles about DDD, this would be a nice use-case for a Domain Service. Ideally, I would inject that service using dependency injection but this ruins the constructor of my domain model. Alternatively, I can demand an instance of a domain service as a function argument like so: public void SetUsername(string value, IUsersDomainService service) and to be honest I don't see any solid alternatives.

Who has faced this problem and maybe came up with a nice rock-solid solution?

domain-driven-design c#
1 Answers

I agree with @TomTom. But as most times with software decisions, it depends, there is almost always a tradeoff. As a rule of thumb, you gain more by not injecting a domain service into an entity. This is a common question when one is starting with DDD and CQRS+ES. And has been thoroughly discussed in the CQRS mailing list here

However, there are some cases where the approach you suggested (known as method injection) might be beneficial it depends on the scenario. I’ll try and drive some analysis points next.

Consider the case where you want to make some validation before creating an entity. Let's think of a hypothetical and way oversimplified international banking context, with the following entity:

public class BankNote
{
    private BankNote() {}

    public static FromCurrency(
        Currency currency,
        ISupportedCurrencyService currencyService)
    {
         currencyService.IsAvailable(currency);
    }
}

I am using the factory method pattern FromCurrency inside your entity to abstract the entity creation process and add some validation so that the entity is always created in the correct state.

Since the supported currencies might change overtime, and the logic of which currencies are supported is a different responsibility than the bank note issuing logic, injecting the ISupportedCurrencyService in the factory method gives us the following benefits:

By the way, the method dependency injection for domain services is suggested in the book: Hands-On Domain-Driven Design with .NET Core By Alexey Zimarev. Chapter 5 "Implementing the Model" page 120

Pros

  • The BankNote is always created with a supported Currency, even if the currencies supported change overtime.
  • Since we are depending on an interface instead of a concrete implementation, we can easily swap and change the implementation without changing the entity.
  • The service is never stored as an instance variable of the class, so no risk of depending on it more than we need.

Cons

  • If we keep going this way we might add a lot of dependencies injected into the entity and it will become hard to maintain overtime.
  • We still are adding a loosely coupled dependency to the entity and hence the entity now needs to know about that interface. We are violating the Single Responsibility Principle, and now you would need to mock the ISupportedCurrencyService to test the factory method.
  • We can’t instantiate the entity without depending on a service implemented externally from the domain. This can cause serious memory leak and performance issues depending on the scenario.

Another approach

You can avoid all the cons if you call the service before trying to instantiate the entity. Say having a different class for the factory instead of a factory method, and make that separate factory use the ISupportedCurrencyService and only then call the entity constructor.

public class BankNoteFactory
{
    private readonly ISupportedCurrencyService _currencyService;

    private BankNoteFactory(
        ISupportedCurrencyService currencyService) 
            => _currencyService = currencyService;

    public BankNote FromCurrency(
        Currency currency)
    {
         if(_currencyService.IsAvailable(currency))
             return new BanckNote(currency);
             // To call the constructor here you would also need 
             // to change the constructor visibility to internal.
    }
}

Using this approach you would end with one extra class and an entity that could be instantiated with unsupported currencies, but with better SRP compliance.

user_89351640
Related