Mudanças entre as edições de "Arquitetura Classpad"
(Criou página com '=Informações Gerais= == Ambientes utilizados == {| class="wikitable" |- ! Ambiente ! URL de Acesso ! Credenciais Admin |- | Desenvolvimento | http://dev-mscro.mstech.com.br...') |
(→Decisões de Arquitetura) |
||
| Linha 43: | Linha 43: | ||
=Decisões de Arquitetura= | =Decisões de Arquitetura= | ||
| − | |||
| − | + | ==== Persistência ==== | |
| + | Através de banco de dados relacional | ||
| + | Criação do banco de dados PostgreSQL nos servidores e em Realm nos dispositivos | ||
| − | + | ==== Tecnologia de integração ==== | |
| + | Será realizada por meio de troca de mensagens entre os dispositivos e o servidor Datacenter e/ou servidor na escola | ||
| + | Tráfego via WSS entre servidores e dispositivos | ||
| + | Tráfego via HTTPS entre servidores e entre servidores e dispositivos | ||
| − | |||
| − | + | ==== Log ==== | |
| + | Implementado log de negócio (para rastreabilidade das ações do usuário) e de log técnico para análise de funcionamento e falhas | ||
| + | Para os logs utilizamos arquivos de texto gerenciado pelo LOG4J2 | ||
| + | Para crash report usaremos Crashlytics (Fabric.io) | ||
| − | |||
| − | + | ==== Padrão de arquitetura utilizado ==== | |
| + | Utilizamos Servidores HTTPS RESTful na arquitetura JAX-RS para gerenciamento de APIs. | ||
| + | Utilizamos o padrão de arquitetura DDD (Domain Driven Design) na aplicação web para ambiente de administração do servidor. | ||
| + | Utilizamos o padrão “thin client” para os dispositivos. | ||
| + | Utilizamos o padrão PubSub na comunicação durante uma sessão de aprendizagem | ||
| + | Utilizamos o protocolo MDNS (Bonjour) para descoberta do servidor da escola | ||
| + | Utilização de Jetty 9 para servidor HTTPS e WSS. | ||
| + | Utilização de Hibernate 4 para comunicação com banco de dados PostgreSQL e SQLite. | ||
| + | Utilização de JMDNS para Discovery na rede. | ||
| − | |||
| − | + | ==== Tecnologia de Front-end ==== | |
| + | Utilização do design nativo Android | ||
| + | Utilização de front end simplificado nos ambientes de Administração | ||
| + | Aplicação de Material Design no Android e Angular-JS na Web | ||
| − | + | ||
| + | ==== Tecnologia de Back-end ==== | ||
| + | Arquitetura padrão para servidores Java e clientes Android | ||
| + | Utilização de Java 7 e Android 4.4 ou superior | ||
| + | |||
| + | |||
| + | ==== Deploy ==== | ||
| + | Distribuição dos clientes android via Google Play | ||
| + | Instalação dos servidores via instalador | ||
| + | Pacotes de instalação APK versionados e assinados conforme padronização | ||
=Fundamentações das decisões tomadas= | =Fundamentações das decisões tomadas= | ||
Nesta seção, coloque todas as considerações das tomadas de decisão realizadas para o produto. Porque foi usada tal arquitetura? Porque essa separação de componentes? Porque houve refatoração? Descreva o máximo possível nesta seção para que o histórico das decisões seja armazenado para consultas futuras. | Nesta seção, coloque todas as considerações das tomadas de decisão realizadas para o produto. Porque foi usada tal arquitetura? Porque essa separação de componentes? Porque houve refatoração? Descreva o máximo possível nesta seção para que o histórico das decisões seja armazenado para consultas futuras. | ||
Edição das 12h36min de 27 de maio de 2016
Índice
Informações Gerais
Ambientes utilizados
| Ambiente | URL de Acesso | Credenciais Admin |
|---|---|---|
| Desenvolvimento | http://dev-mscro.mstech.com.br | admin / 123456 |
| Testes | http://tst-mscro.mstech.com.br | admin / ms@cro |
| Testes | http://tst-mscro.mstech.com.br | admin / ms@cro |
| Homologação Externa | http://hom-mscro.mstech.com.br | Informação exclusiva do Devops/GTI |
| Produção | http://mscro.mstech.com.br | Informação exclusiva do Devops/GTI |
Repositório de Versionamento
Ambiente: GITLab - Git
Nome: MSCRO
Caminho: https://gitlab.mstech.com.br/mscro/app-mscro.git
Estrutura dos branches: Código mantido no tronco, porém mantemos 2 branches para os clientes SP e RJ.
Visão de Componentes
Apresente um diagrama básico dos módulos do sistema, bem como suas fronteiras. Descreva sucintamente cada módulo que compõe o produto, seu objetivo e como foi construído (linguagens usadas, bancos de dados, etc.).
Decisões de Arquitetura
Persistência
Através de banco de dados relacional Criação do banco de dados PostgreSQL nos servidores e em Realm nos dispositivos
Tecnologia de integração
Será realizada por meio de troca de mensagens entre os dispositivos e o servidor Datacenter e/ou servidor na escola Tráfego via WSS entre servidores e dispositivos Tráfego via HTTPS entre servidores e entre servidores e dispositivos
Log
Implementado log de negócio (para rastreabilidade das ações do usuário) e de log técnico para análise de funcionamento e falhas Para os logs utilizamos arquivos de texto gerenciado pelo LOG4J2 Para crash report usaremos Crashlytics (Fabric.io)
Padrão de arquitetura utilizado
Utilizamos Servidores HTTPS RESTful na arquitetura JAX-RS para gerenciamento de APIs. Utilizamos o padrão de arquitetura DDD (Domain Driven Design) na aplicação web para ambiente de administração do servidor. Utilizamos o padrão “thin client” para os dispositivos. Utilizamos o padrão PubSub na comunicação durante uma sessão de aprendizagem Utilizamos o protocolo MDNS (Bonjour) para descoberta do servidor da escola Utilização de Jetty 9 para servidor HTTPS e WSS. Utilização de Hibernate 4 para comunicação com banco de dados PostgreSQL e SQLite. Utilização de JMDNS para Discovery na rede.
Tecnologia de Front-end
Utilização do design nativo Android Utilização de front end simplificado nos ambientes de Administração Aplicação de Material Design no Android e Angular-JS na Web
Tecnologia de Back-end
Arquitetura padrão para servidores Java e clientes Android Utilização de Java 7 e Android 4.4 ou superior
Deploy
Distribuição dos clientes android via Google Play Instalação dos servidores via instalador Pacotes de instalação APK versionados e assinados conforme padronização
Fundamentações das decisões tomadas
Nesta seção, coloque todas as considerações das tomadas de decisão realizadas para o produto. Porque foi usada tal arquitetura? Porque essa separação de componentes? Porque houve refatoração? Descreva o máximo possível nesta seção para que o histórico das decisões seja armazenado para consultas futuras.
