Should I validate inside DDD domain project?

Question

I want to validate my domain model entities using FluentValidation. I have read an answer about validation in DDD that has used FluentValidation for validating his entity. Here is how he validate its entity:

public class ParticipantValidator : AbstractValidator<Participant>
{
    public ParticipantValidator(DateTime today, int ageLimit, List<string> validCompanyCodes, /*any other stuff you need*/)
    {...}

public void BuildRules()
{
         RuleFor(participant => participant.DateOfBirth)
                .NotNull()
                .LessThan(m_today.AddYears(m_ageLimit*-1))
                .WithMessage(string.Format("Participant must be older than {0} years of age.", m_ageLimit));

        RuleFor(participant => participant.Address)
            .NotNull()
            .SetValidator(new AddressValidator());

        RuleFor(participant => participant.Email)
            .NotEmpty()
            .EmailAddress();
        ...
}

}

So my Domain Project is depend on FluentValidation library.

But I think it is bad Idea that my Domain Project depends on third party library. How I can prevent this problem?

Here's my take on the subject. Your question is pretty much a duplicate of http://stackoverflow.com/questions/28395176/should-i-abstract-the-validation-framework-from-domain-layer/28397201#28397201 — plalx, Sep 03 '15 at 21:46
@SeyedMortezaMousavi Having the domain depend on a third party library only becomes a bad idea if said library is coupled to low-level stuff such as web-related or persistence-related components. — guillaume31, Sep 04 '15 at 11:44
Validation is a part of business logic, despite misleading feeling, made by declarative style of rules. It is good practice to place validators in separate project. — David Levin, Sep 08 '15 at 14:40
As soon as your entities don't depend nor rely on this third party library, it's ok and valid. Actually, the idea behind having the domain layer, is to have a common language between programmers and people from businness area, so it should be the most clean and natural possible, so you could show the domain to a business analyst and make they understand. If the validation code has validations which make sense to the business, it's valid, actually a business analyst could see it and makes points (e.g this validation rule should be that way). Your validation code looks fine to business. — Alisson Reinaldo Silva, Nov 29 '15 at 14:06
@AlissonReinaldoSilva can you paste your comment as answer. So I can make it as answer? — Seyed Morteza Mousavi, Nov 29 '15 at 15:19

score 7 · Accepted Answer · edited Mar 11 '21 at 21:55

As soon as your entities don't depend nor rely on this third party library, it's ok and valid. Actually, the idea behind having the domain layer, is to have a common language between developers and people from the business area, so it should be the most clean and natural possible. Then you could show the domain to a business analyst, make sure they understand it and discuss further. If the validation code has validations which make sense to the business, then it's valid. Actually a business analyst could even see it and make additional observations (e.g this validation rule should be that way). Your validation code looks fine to business.

Should I validate inside DDD domain project?

1 Answers1