We are having a heated discussion about this at work:For sake of simplicity, I will use examples in the question.Assume there is an application with an account request form, for which we have these requirements:Dates and Email must match a regexIf the user already has an account request, he should not request for anotherThe problem is: where to verify the second requirement?If we check on the controller, we would have to access the database from there and it is a business logic, so it doesn't seem right.If we validate on the business layer, we would have to somehow return the validation information in case of a failed validation. Doing this would require either:Each business method to have an out parameter;We to encapsulate our return object into a response object with the validation informationThe use of exceptions in case of failed validations (which, to me, falls in the anti-pattern of using exceptions for programm flow).How should we design this?
Where should I place business logic validations?
architecture
Go for the second solution. Your AccountRequestValidator uses the db information and some rules to determine of the request is valid or not. Then use a response object, but don't create one yourself if you use a language that has already implemented that for you like Scala or Haskell. This type is usually called Either. It should throw an Exception if it is not able to check if the validation is valid, for whatever reasons there might be.Your code would therefore look similar to:AccountRequestValidator validator = new AccountRequestValidator(db)AccountRequest request = //...try {    Either<RequestAllowed, RequestForbidden> validationResult = validator.validate(request )    //Do sth. with validationResult}catch (Exception e) {    //Was unable to check if the request is valid...}If you use Java, consider using Googles Functional Java. It has its own Either type defined.