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

There are straight answers for your questions. So I put the answers with no background.

In which layer should the validations be done mainly?

Both server and client side for more accurate and secure applications. Regardless of design context. For server side you may employ different ways like fluent validation or Data Annotation (Model) or bring them to client with integration libraries like jquery-unobtrusive-ajax. Server side validation is more important, since CRUD operations needs to be validated to avoid anomalies and etc .... In terms of your question, layers are View and Model (Data Access).

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's acceptable, required fields or empty values for required dependencies fires error when you show or process data store in Database. Here, there is no speaking about changes which can be over time. We only consider now. We employ patterns and programming rules to create flexibility/maintainability. Validations and entry dependencies can be changed over time.

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 ?

Showing exception in client-side is a good technique for development days or notifying corresponding user about the error which prevents data to be changed/stored. considering that: some systems really have no strategy to show additional info to the end user. Some reports can make the app more vulnerable to intrude. This is completely based on the software type you are developing. A good practice is showing a simple error in client-side and store error logs inside server (with comprehensive details).

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?

Some people may have personal architectures with their own naming. But some of them are official and widely used like Unit Of Work or Repository Pattern which add some layers to famous pattern (MVC) to achieve more accurate, clean and maintainable code/application. Follow the main purpose behind any pattern.

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 ? When Should I use Business Rule Framework (BRF) instead?

FluentValidation is an alternative to DataAnnotations working like the FluentAPI. Note that both used to define rules for properties belonging to a defined class (a database table). There's a concept named ViewModel which contains a transformation(with some changes) for Main Model class (Table) mainly targeting the validation in front-end. You may employ both for a project, mapping each Model to its ViewModel or vice versa. If you are using a repository pattern, say, have a Data Access Layer, So some of the validation is inside this layer. If you're using ViewModel, so it's inside application layer. But, As an advice, These are worthless. The key success is to understand main purpose behind any technique/architecture/pattern. You can find tons of article around each of them and focus on purpose, then you can decide what to do to have a more clean/standard/maintainable/flexible/etc... code.

And the Final Tip : Increasing the modularity increases the cost to integration (software cost) Although decreases cost for each module. Use a moderate design for your project. Combining architectures sometimes not only is not a good idea but also increases the cost and development hardships. More details in software design basics

Answer 2

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

Answer 3

There are actually several different activities that might be called "validations", and they are all handled somewhat differently.

Message validation usually happens as close to the boundary as we can manage. When I receive an HTTP request, I'm going to verify that the request itself is well formed, that the right media type is specified in the meta data, that the request body can be processed cleanly, that the resulting DOM has all of the required fields, that the known data nodes are all of the appropriate type, that the values present are within the allowed ranges, all before I worry about the current state of the domain model.

Often, this validation takes the form of transforming the data from the message into a graph of value objects in the domain; that will usually look like factories or builders that know how to take domain agnostic value types and convert them into domain specific values. The domain model won't normally know anything about the message format, and won't know about the serialization (JSON is not normally a domain concern).

There is a similar separation of concerns when reading values from the persistent store - the value factories will know how to create values from primitives, but won't necessarily know anything about JSON, or results sets, and so on.

The "business logic", which validates whether a given message is meaningful given the current state of the domain, usually lives within the domain model.

Is it acceptable for the object to be in invalid state?

It shouldn't ever be acceptable for an object to be in an invalid state.

BUT there are valid states that aren't reachable. Negative account balances are becoming a significant liability for the company, so a new business rule is introduced that prevents withdrawals that would result in a negative balance. That doesn't change the fact that Bob's account balance is negative. It's still a valid state, just one that isn't reachable with the new rules.

When to return messages and when to throw exceptions in the validation context ?

Don't use exceptions to implement contingency management.