Should I perform simple validation (not null, max length, etc.) in a web api controller and duplicate in a command handler?

Question

I have a question about DDD. I wonder if I should add validation in a web api controller and duplicate it in a command handler? Is it good approach to validate a DTO and a command even if the validation is the same?

For example, here I used data annotation validation attributes for a controller:

public class EmailsController : ControllerBase
{

    [HttpPost]
    public async Task<IActionResult> SendEmail(CreateEmailMessageDTO emailMessage)
    {
        await _mediator.Send(new SendEmailCommand(emailMessage.Email, emailMessage.Subject, emailMessage.Message));
        return NoContent();
    }
}

// Data Annotation Validation:
public class CreateEmailMessageDTO
{   
    [Required]
    [EmailAddress]
    public string Email { get; set; }

    [Required]
    public string Subject { get; set; }

    [Required]
    public string Message { get; set; }
}

And FluentValidation for a command:

public class SendEmailCommand : IRequest
{
    public string Email { get; }
    public string Subject { get; }
    public string Message { get; }

    public SendEmailCommand(string email, string subject, string message)
    {
        EmailFrom = emailFrom;
        Subject = subject;
        Message = message;
    }
}


// FluentValidation:
public class SendEmailCommandValidator : AbstractValidator<SendEmailCommand>
{
    public SendEmailCommandValidator()
    {
        RuleFor(x => x.EmailFrom)
            .NotEmpty()
            .EmailAddress();

        RuleFor(x => x.Subject)
            .NotEmpty();

        RuleFor(x => x.Message)
            .NotEmpty();
    }
}

Answer 1

I wonder if I should add validation in a web api controller

Probably - although you might want parsing, rather than validation. Making your checks in the controller both simplifies your error handling (the controller can readily reply to messages that don't parse with a client error using the appropriate status code) and also simplifies the rest of your code (which can work with a trusted in memory representation of information).

Important note: CreateEmailMessageDTO is an in memory representation of a message in your API. You might have, for example, an API document that describes a CreateEmail message, which fields are required, which are optional, other constraints on the information. The parsing you are doing here is to ensure that the general purpose information structure you have been passed satisfies the stricter constraints of your API schema.

---

Is it good approach to validate a DTO and a command even if the validation is the same?

Often, not always.

The trick is that our API constraints and our data model constraints change for different reasons; it can be useful to make that distinction explicit in the code (there's some tension between "expressive" and "YAGNI").

During the period where they are the same, you might want to make them the same (these two cases both delegate to the same thing... or each delegate to local routines that are generated from the same constraint definitions). There are a lot of possibilities here, depending on where you want the dependency arrows to go.

For instance, CreateEmailMessageDTO.Email and SendEmailCommand.Email likely use "the same" validation because they are both coupled to the production rules defined by RFC 5322.

You might solve this by implementing the validation twice, or having both of these delegate to a common implementation, or by generating "different" validators from the same production rules. Welcome to trade offs.

Continuing to support validation on the command object can still be valuable if there are other code paths that produce command objects without going through the web api models.

Answer 2

First, you need to step back and take a lager picture of what you are doing.

The purpose of the domain layer is to model your business concepts using OOP, and implement business requirements checks to ensure your service integrity, business-wise. All operations in that layer are application independent and should execute in any piece of software related to that domain.

The presentation layer, on the other hand, is responsible for mediation between customer facing interface of a specific application, and this application's other layers. Frameworks such as asp.net webapi hide some cross cutting concerns such as authentication, and does serialization/deserialization for you, so you are left with less code to write for this layer.

Put another way, the presentation layer is responsible for enforcing your interface specification, and your domain layer is responsible for enforcing business requirements. The relevant object models for these two might differ, which is why you may have conversion operations, and presentation level validation may not suffice to enforce business invariants.

Now, where to validate ? The answer is quite straightforward. If your validation is a business requirement (I cannot send an email from a malformed email address, whatever the application), then this validation should happen in the domain layer. If the email formatting is a requirement in your interface specification (EmailsController expects CreateEmailMessageDTO.Email conforming to RFC), then validation should happen in the presentation layer.

Business requirements should never depend solely on presentation layer validation, otherwise business integrity depends on interface specification, violating the single responsibility principle (SRP) and DDD principles (domain validation happens in the domain layer only). But what if the validation is both a business requirement and an interface specification ?

You basically have two options :

• implement in business layer only
• implement in both layers

Implementing the validation in business layer only is obviously cheaper and easier, don't-repeat-yourself (DRY) approach, as you need to write less code, so your application is smaller, easier to understand and maintain. Your presentation layer does not need to validate because the domain layer will do that for you, just think of that as a delegation. The drawback is that, sometimes, business layer validation can happen quite late in the request life-cycle. You will eventually need to query business data from the persistence layer before being able to validate your business state. In this situation, it's up to you to decide whether you prefer to fail early by adding a presentation layer validation or keep the code smaller.

In your situation though, the additional cost of adding email format validation in the presentation layer is very small, both at the code maintenance level and the runtime execution footprint level. Doing both validation seems acceptable, unless you are in a specific context, such as very high throughput low available memory, which might advocate for smallest footprint over maintainability. However in such situation you might reconsider your overall architecture, but that's another topic.

Answer 3

You should have 1 DDD tier (layer) that performs validation check on values being in the valid range, not 2 tiers. Ideally upon validation, you would change the type from UnvalidatedX to AlreadyValidatedX (or shorter identifiers/acronyms of your team's choosing) in a strongly-typed language that would enforce this strong typing at engineering-time (e.g., compile-time), then utilize only AlreadyValidatedX henceforth for all interior tiers of processing. More-interior tiers would utilize the AlreadyValidatedX type and never utilize the UnvalidatedX type whatsoever. In this viewpoint, the answer to OP's question becomes trivially obvious. Such strong typing is present in TypeScript; the lack of such strong typing is present in JavaScript—hence why TypeScript was invented to provide strong typing to JavaScript to catch such bugs as usage of unvalidated input at engineering-time. In this viewpoint, the validation would occur just prior to instantiating a DTO that carries instances of AlreadyValidatedX further interior to the system.

But we live in an imperfect world where some interior tier might be implemented in a programming language that lacks strong typing (or that goes through a glue layer where the strong typing of one programming language is not relayed to another programming). Thus, your team would need to enforce such rules via coding standards, team engineering practice, and code reviews—hence why strongly-typed languages are preferable to automate this otherwise costly manual labor. The closer that human beings who are (for whatever reason) using a weakly-typed set of programming languages can emulate via labor the automation that would have been provided by using strongly-typed programming languages whose types interwork between tiers, the better.