Os dados de negócio serão representados por objetos Java simples que atravessarão as camadas da aplicação. As classes que representam as entidade de negócio serão referenciadas pelas camadas persistence (persistência), enterprise (corporativa se existir), service (serviços) e client (cliente), formando assim uma camada transversal na arquitetura lógica que será chamada entity (entidades).
Com esta escolha, a camada de persistência tem como papel transformar o conteúdo da camada de dados em entidades, representação do modelo do objeto de negócio. Este modelo comporta alguns aspectos técnicos ligados à um framework de persistência quando for possível realizar o mapeamento objeto-relacional dos JavaBeans simples. Em contrapartida, esta estrutura não permite generalizar uma especialização de dados de negócio por camada. Esta limitação foi aceita em relação à produtividade e desempenho trazidos por esta solução.
A funcionalidade das aplicações será implementada nas classes chamadas serviços, distintas das entidades de negócio. Não deverá existir nos objetos de negócio atributos e operações complexas. Os serviços constituem as camadas de persistência, enterprise e de serviço.
Visando uma maior flexibilidade e reutilização dos serviços, de acordo com a arquitetura orientada à serviço (SOA), estes deverão ser preparados para sofrer DI (Dependency Injection). Estas classes deverão possuir um ou mais métodos setter para receber a interface de cada dependência que será implementada ou deverão existir construtores específicos para receber as interfaces das dependências entre os serviços utilizados.
No caso da camada de persistência, os serviços serão chamados DAO referindo-se ao padrão de desenvolvimento Data Access Object RF03. O seu papel é oferecer serviços de persistência às entidades apoiando-se nas soluções retidas (frameworks de persistência).
A camada cliente realiza geralmente a interface entre o usuário e o sistema. Ela não deverá conter lógica funcional, com exceção de controles eventuais na camada superficial que devem ser realizados, não deve substituir os controles da camada de negócio (service e enterprise) mas poderá constituir redundância com objetivo meramente ergonômico.
Esta prática visa isolar a funcionalidade dos aspectos de apresentação e navegação que são geralmente complexos e particularmente técnicos. Assim a evolução das funcionalidades será mais fácil de ser realizada. Por outo lado, esta estrutura facilita as mudanças IHM do ponto de vista técnico sem risco de perder ou alterar uma regra de negócio. Será possível possuir simultaneamente várias IHM para uma mesma aplicação (por exemplo, um cliente simples e outro com vários detalhes de tela) sendo que o essencial é centralizado.
A camada de persistência e conectores realiza a interface com as bases de dados ou outros sistemas externos. Não deverá conter lógica funcional.
As regras precedentes se resumem da maneira seguinte: a funcionalidade das aplicações serão centralizada nas camadas de serviço e enterprise (se existir) e os dados nas entidades da aplicação. Estas camadas constituem o core (núcleo) das aplicações. As outras camadas se contentam em realizar a interface com os usuários ou outros sistemas.
 |
Com esta escolha, a camada de persistência tem como papel transformar o conteúdo da camada de dados em entidades, representação do modelo do objeto de negócio. Este modelo comporta alguns aspectos técnicos ligados à um framework de persistência quando for possível realizar o mapeamento objeto-relacional dos JavaBeans simples. Em contrapartida, esta estrutura não permite generalizar uma especialização de dados de negócio por camada. Esta limitação foi aceita em relação à produtividade e desempenho trazidos por esta solução.
A funcionalidade das aplicações será implementada nas classes chamadas serviços, distintas das entidades de negócio. Não deverá existir nos objetos de negócio atributos e operações complexas. Os serviços constituem as camadas de persistência, enterprise e de serviço.
Visando uma maior flexibilidade e reutilização dos serviços, de acordo com a arquitetura orientada à serviço (SOA), estes deverão ser preparados para sofrer DI (Dependency Injection). Estas classes deverão possuir um ou mais métodos setter para receber a interface de cada dependência que será implementada ou deverão existir construtores específicos para receber as interfaces das dependências entre os serviços utilizados.
No caso da camada de persistência, os serviços serão chamados DAO referindo-se ao padrão de desenvolvimento Data Access Object RF03. O seu papel é oferecer serviços de persistência às entidades apoiando-se nas soluções retidas (frameworks de persistência).
A camada cliente realiza geralmente a interface entre o usuário e o sistema. Ela não deverá conter lógica funcional, com exceção de controles eventuais na camada superficial que devem ser realizados, não deve substituir os controles da camada de negócio (service e enterprise) mas poderá constituir redundância com objetivo meramente ergonômico.
Esta prática visa isolar a funcionalidade dos aspectos de apresentação e navegação que são geralmente complexos e particularmente técnicos. Assim a evolução das funcionalidades será mais fácil de ser realizada. Por outo lado, esta estrutura facilita as mudanças IHM do ponto de vista técnico sem risco de perder ou alterar uma regra de negócio. Será possível possuir simultaneamente várias IHM para uma mesma aplicação (por exemplo, um cliente simples e outro com vários detalhes de tela) sendo que o essencial é centralizado.
A camada de persistência e conectores realiza a interface com as bases de dados ou outros sistemas externos. Não deverá conter lógica funcional.
As regras precedentes se resumem da maneira seguinte: a funcionalidade das aplicações serão centralizada nas camadas de serviço e enterprise (se existir) e os dados nas entidades da aplicação. Estas camadas constituem o core (núcleo) das aplicações. As outras camadas se contentam em realizar a interface com os usuários ou outros sistemas.