Uhm, vamos tentar elaborar o ponto. Mapear logica de negocios qualquer programa, em qualquer paradigma pode fazer, concorda? Uma aplicacao em pascal mapeia regras de negócio em funções e estruturas de dados.
Então quando utilizamos os objetos nós apenas os utilizamos para mapear regras de negócio, correto? Agora como fazemos?
No Domain Model nós os vamos mapear através da modelagem de entidades do mundo real em objetos. Adicionando Domain-Driven Design e Domail Driven modeling em geral temos um mapeamento mais próximo do 1-para-1 quanto possivel.
No Transaction Script nós vamos mapear os processos do mundo real em objetos.
Em ambos os modos utilizamos objetos pra modelar regras de negócio, um focado em conceitos como entidades e outro levando os processos.
Meu conceito de objetod e negócio é um objeto que realiza regra de negócio, logo ambos cabem na definicção.
Na verdade eu respondi sim, só que fui muito raso, acho.
Basicamnete utilizar Camadas significa que você vai separar os objetos por responsabilidade em grandes áreas, e geralmente estas áreas são interface, negócios e persistência. Se seu objeto de interface (a Action) possui lógica de negócios significa que você não está utilizando Camadas, ao menos não corretamente.
Este tópico fala em arquitetura de camadas, especificamente sobre Camada de Negócios
Ai que está o meu ponto onde estou sendo meio chato…
Objetos de negócio são os que realizam a lógica de negócio segundo você.
Beleza!
Em sistemas mal projetados (existem muitos) os objetos de negócio seriam aqueles em que o usuário colocou sua regra de negócio, mesmo que seja um action - segundo sua definição. Ou seja, a sua definição está correta desde que o sistema esteja bem projetado, o que não é o caso de muitos.
A minha definição é na verdade bem restrita, mas eu me sinto confortável porque não da margens a alguem chamar um action de objeto de negócio hehe… bom… como ja disse é uma questão mais pessoal…
Sobre o foco ehe… acabmos caindo numa disucssão mais teorica do que prática pra ajudar o autor hehe mas se ele estiver lendo ótimo… Até porque na engenharia de software ainda nos podemos nos dar o luxo de “entender do nosso jeito” (com coerência é claro, mesmo sendo difícil as vezes) e nao ter que decorar definições já feitas… mas isso tem seu ponto negativo também…
Sobre o assunto nao se preocupe, o GUJ eh conhecido por nao ser apenas um helpdesk e sim pontod e discussoes. Aidna estamsod entro do topico Camada de Negocios e caso saiamos dele pdoemos criar outro topico para continuar a discussão.
Sobre os sistemas mal projetados, acredito que oproblema eh an cosntrução dos sistemas em si e não no conceito de objetos de negócio. Quando se deparar com um sistema deste tipo creio que o melhor seja avaliar os meritos tecnicos deste, nao restringir um conceito que eh amplo por natureza apenas para nao endossar uma ma pratica. De qualquer forma entendi sua preocupacao.
