title: Swagger spec's validation overriding FluentValidation
body: <p>I am having the following problem, and so far haven't been able to find an effective solution for it. I have the following code in my <code>Swagger</code> spec:</p>
  <pre><code>    SomeRequest:
            type: object
            properties:
              client_date_of_birth:
                type: string
                format: date
                example: &quot;2021-09-17&quot;
            required:
               - client_date_of_birth
  </code></pre>
  <p>This of course works fine, but the problem is introduced when I try to use <code>FluentValidation</code> instead of this approach. My <code>FluentValidation</code> code looks like this:</p>
  <pre><code>.RuleFor(i =&gt; i.ClientDateOfBirth)
                  .NotEmpty().WithMessage(&quot;Client's Date of Birth is empty&quot;)
                  .InclusiveBetween(new LocalDate(1870, 01, 01), todayDate);
  </code></pre>
  <p>I wish to display the <code>FluentValidation</code> message instead of the generic one from <code>Swagger</code>, but so far I haven't found a good way to do this.</p>
  <p>If I remove <code>client_date_of_birth</code> as a required field, I will also open up the API's contract to allow this field as a <code>null</code> value (which I want to deal with at API level, not <code>FluentValidation</code> level) and if I set it up as a <code>string</code> instead of a <code>date</code>, I will also be opening up the API's contract to potentially unwanted behavior. Is there a way to override this particular behavior of <code>Swagger</code> with the <code>FluentValidation's</code> implementation?</p>
  <p><strong>Just as a clarification:</strong> I know I will get the <code>FluentValidation</code> error message if I remove the <code>client_date_of_birth</code> as a required field in the <code>Swagger</code> spec. My question is more about: can I override <code>Swagger's</code> behavior with <code>FluentValidation's</code>? the reason I want to keep it in both places is so the rules of the API's contract are transparent and written in the spec itself, rather than obscure and hidden in the code, even if I will be eventually using said code.</p>