In which layer should the validations be done mainly in the context of DDD?

Question

This question might be asked a thousand of times but a lot of confusions and contradictions in the answers.

I ask about the validations in the context of domain driven design.

1. In which layer should the validations be done mainly ?
2. Is it acceptable for the object to be in invalid state? because many answers said that it's okay and mainly because of historical data and the business rules may change over time and loading historical data might cause problems?
3. Many implementations consider throwing exceptions in the domain layer and mapping the messages to the UI although Martin Fowler recommends to Replacing Throwing Exceptions with Notification in Validations! When to return messages and when to throw exceptions in the validation context ?

4. Many articles explain some tips or paths to follow like Vladimir Khorikov and jbogard in their articles but in the comments they confess that they do things a wee differently now. Are these patterns still valid?

5. Should I use framework like FluentValidation and if I use it, Is this frame work used only in the application layer as an alternative to the MVC annotations ?

6. When Should I use Business Rule Framework (BRF) instead?

---

I know many questions here but they target the same spot(Validation in DDD).

Note: I don't use CQRS pattern because it made the application so complex. So I have (domain layer,data layer, application layer(MVC), and shared kernel)

Answer 1

In which layer should the validations be done mainly ?

Mainly in Domain, except for infrastructure related validation, e.g. xsd validation or json schema for instance.

Is it acceptable for the object to be in invalid state? because many answers said that it's okay and mainly because of historical data and the business rules may change over time and loading historical data might cause problems?

It can be acceptable, because validation is done into domain it should not be the case. On a point of view of business, objects cannot be in an invalid business state, however, some times, like in the real life, process can be in an invalid/temporary state. We call it eventual consistency (https://en.wikipedia.org/wiki/Eventual_consistency), I suggest you take a look at this. At the end the system will be in a valid state and that's all that matter, if its temporarily invalid, well, the effort might be bigger to maintain such system but sometimes you have no choice.

Many implementations consider throwing exceptions in the domain layer and mapping the messages to the UI although Martin Fowler recommends to Replacing Throwing Exceptions with Notification in Validations! When to return messages and when to throw exceptions in the validation context ?

I am not a big fan of exceptions in the domain layer unless this is clearly a pre-requisite thesis broken. For instance an input too large for a field, or a negative price for an item. If you cannot build a valid business object, then in my opinion this is a very valid case for an exception. In case this is a business case, a message is best suited.

Many articles explain some tips or paths to follow like Vladimir Khorikov and jbogard in their articles but in the comments they confess that they do things a wee differently now. Are these patterns still valid?

Should I use framework like FluentValidation and if I use it, Is this frame work used only in the application layer as an alternative to the MVC annotations ?

Best recommendations in DDD is to never use framework, Spring or JDBC might help however but in general you should do it by hand. We have written even stores by hand, application services and Oracle projections and event bus. Its more faster, more maintainable, and you learn a lot more. Vaughn Vernon in his book (Implementing Domain Driven Design) gives very good examples and a project you can look at: https://github.com/VaughnVernon/IDDD_Samples (written in Java)

When Should I use Business Rule Framework (BRF) instead?

Again, don't use a framework