Se tenho uma arquitetura composta por exemplo:
Command, Front Controller, Facade, AbstractFactory, DAO etc…
E tenho a minha tela, por exemplo um cadastro de clientes…
Onde fica as validações do tipo… o usuário não preencheu tal campo, tal campo não aceita dados não numéricos!!! Coisas do tipo!!!
Ah!! E outra, se eu tivesse regras de negócio e não apenas as funcionalidades básicas( insert, update,…), quem chamaria a minha classe de negócio?
Valeu!!
Vixe, você gostou desse negocio de padrões hein… é bom tomar cuidado com isso hein…
As validações costumam ficar na View mesmo, já que isso está ligado ao que é mostrado para o usuario…
A ultima eu não entendi…
Por exemplo: Se ao cadastrar o cliente, tivesse que ser feito uma verificação se o cliente tem todas as contas quitadas( não deve nada), ou se tá tudo em dia!! Essa minha classe de negócio que teria essas regras é uma classe à parte? E outra, qual padrão chamaria essa classe contendo essas regras? Tipo um command, sei lá!!
Valeu!!
Não acho que seria uma classe à parte, pois isso faz parte da sua logica de negocio, não há um padrão definido pra esse tipo de coisa…
A ideia de Command não é bem essa…
O BusinessObject não é uma classe de negócios? Achei que tinha uma classe pra esse tipo de coisa! 
Valeu JairElton!
Dessa sopa de padrões, certamente você utilizará somente o Command (Action).
Seja CRUD ou não, elas podem ser chamadas por uma Action.
Não se esqueça que o propósito do padrão Command é encapsular uma requisição como um objeto, permitindo que os clientes parametrizem diferentes requisições.
Se você quer validação no lado do cliente, use JavaScript. Se for no lado do servidor, seu POJO pode ter um método de validação ou uma classe que estenda um Validator, assim como acontece no SpringMVC.