DDD Request Validation Handling

Question

I stuck somewhere that I can't find a solution! There are plenty of validation questions here, but as far as I see, most of them were asking about entity validation. But what about request validation?

I'm developing a service for web application. Basically I have 3 modules which are Web, Domain and Repo. A request for Web project has dependencies to other technologies(JAX-WS auto generated classes) and they are not suitable to be used in domain. So I convert them to new request class to make more suitable for domain service. I also add defaults() and validate() methods to the new request class. So some part of request validation is handled in validate() method. I call them at first line of corresponding method in domain service. So before starting the operation, I know whether request is valid or not. Later on, I have kind-of-validation codes. At this point, I'm not very ensure that which part of the validation truly belongs request validation and which part of it belongs domain service as business logic. I believe every piece of code belongs where it has to be! But sometimes it is hard do decide:D For instance when you need to use repository while you are validating. Let me explain with example.

Let's say you need to do implement a method where customers can be added or deleted from account. Aside null control(validation-phase1), you might check either the customer is valid or not. You need repository. Then you check either account is open or not. You need repository. Boom! Then you do check either customer in request has been already added or you try to delete the customer who doesn't belong to account and so on... May be you think that those situations are not validation, but business logic. I think they are validation, because first, you check customers and account, then do other stuff. What do you think about using repository from validation method, what is your edge for validation? Do you consider above situation I mentioned as a validation? Thanks in advance.

Answer 1

Validation rules are business logic.

Even a simple "NULL" check is a business rule -- someone decided it was OK for "Middle Name" to be missed but "County" must always be filled in.

Most validation rules are not that simple and may even require access to external services e.g. "is the guy on the credit agencies s**t list".

So forget about Validation as a separate step, they are not even a "special" business rule, in any application dealing with external input most of the business rules will be some sort of validation.

Having said that validation falls into two general categories:-

"is the request well formed" -- are the numbers numbers, are compulsory fields filled in etc. these checks can be done up front (often in the requestors web browser) and do not require access to any external data.

"are the contents valid" -- this almost always requires access to other data.

The real problem is confusing a subset of validation "check the request is well formed" with the whole of validation.

Answer 2

First of all, if you have a Account aggregate, and a Customer aggregate, and the business rule for modifying an account by adding a Customer requires looking at the customer state and at the account state, then either your business rules or your model are wrong. The aggregate boundary is to include all of the state needed to enforce the business invariant.

All business rule validation belongs inside the aggregate that owns the state being checked.

All of the validation about the arguments to the command -- is this really a customer, is that number really between 1 and 100, and so on -- that logic belongs outside of the aggregate. It's part of the command validation done by the command handler (although it is useful to have that same validation logic generally available -- the client should be able to validate a command before sending it to the command handler to be passed to the aggregate).