search

code-for-sao-paulo / narededocandidato

Aplicação cívica para monitoramento de posts de candidatos nas redes sociais
Mozilla Public License 2.0
5 stars 1 forks source link

Sugestão arquitetural #1

Open dalssoft opened 8 years ago

dalssoft commented 8 years ago

Descrição da arquitetura

Lista dos candidatos (core)

Essa parte da arquitetura é responsável por guardar e garantir os dados alimentados de maneira manual. É através dessas informações que:

Inicialmente não há necessidade de UI para a manutenção (CRUD) desses dados, sendo mantido via um arquivo de seed (ex: http://davidmles.com/blog/seeding-database-rails/)

Bando de dados

Tabela: candidato

campo descrição
id id único do candidato, seguindo a numeração do TSE/TRE (??)
nome nome do candidato
partido_id FK tabela partido
candidatura_id FK tabela candidatura
data_criacao data de criação do registro
data_atualizacao data de atualização do registro

Tabela: candidatura

campo descrição
id id único do tipo da candidatura (um caractere) (Ex: P - Prefeito, V - vereador)
descricao descrição do tipo de candidatura
data_criacao data de criação do registro
data_atualizacao data de atualização do registro

Tabela: partido

campo descrição
id id único do partido, seguindo a numeração do TSE/TRE
nome nome do partido
data_criacao data de criação do registro
data_atualizacao data de atualização do registro

Tabela: candidato_link

campo descrição
id id único da página (GUID)
candidato_id FK tabela candidato
link URL para um site ou mídia social do candidato
tipo_link_id FK tabela tipo_link
data_criacao data de criação do registro
data_atualizacao data de atualização do registro

Tabela: tipo_link

campo descrição
id id único do tipo do link (dois caracteres) (Ex: FB - Facebook, TT - Twitter)
descricao descricao do tipo do link
data_criacao data de criação do registro
data_atualizacao data de atualização do registro

Info: é importante manter as tabelas normalizadas e suas constraints ligadas entre os relacionamentos, garantindo que os dados aqui não sejam corrompidos. Outras tabelas, como as do crawler, talvez não necessitem do mesmo rigor.

Client / UI: Home, páginas e filtros [~/client]

[TBD]

Crawler 1: Posts da página do candidato [~/crawler/posts]

Atualiza quais os posts de cada página (no FB) de cada candidato nos últimos N dias.

Bando de dados

[TBD]

Parametros

Atualiza quantos likes e quantos comentários cada post tem.

Bando de dados

[TBD]

Parametros

dalssoft commented 8 years ago

aqui eu fiz sugestão da divisão de algumas camadas, uma modelagem inicial para o core, alguns sugestões de pastas para o projeto e padrões de nomenclatura (foi o primeiro que o google trouxe).

fica faltando um monte de coisas: definição da arquitetura do client/ui, dos crawlers, etc.

mvcds commented 8 years ago
mvcds commented 8 years ago

Se entendi a proposta da seed, é preencher o banco com dados pré-definidos. Pode ser uma boa ideia para um momento futuro, mas enquanto estamos em concepção podemos usar algo como o rosie junto ao faker, para criarmos algo que se assemelha aos modelos.

O problema dessa abordagem é que são dados falsos, mas podemos começar a testar a modelagem com eles antes de inserir dados reais.

danielbdias commented 8 years ago

Achei a modelagem inicial ok.

O único comentário sobre ela é que eu sugiro termos ids separados dos ids dos órgãos governamentais (o caso das tabelas candidato e partido).

A modelagem ficaria algo como:

campo descrição
id id único
codigo_tse id segundo o TSE

Para a criação das seeds e para a criação dos migrations eu sugiro que a gente use o db-migrate.

alanhoff commented 8 years ago

Por mim está tudo OK somente optaria for fazer logo uma API em vez de um site estático pois o mesmo terá constantes atualizações.

Uma estrutura de projeto que vem funcionando muito bem para mim é esta:

|-> index.js
|-> frontend (talvez rodar em um projeto separado)
|-> libs
      |-> server.js
      |-> ...
| -> resources
       |-> partidos
             |-> model.js
             |-> schemas.js
             |-> routes.js
             |-> handlers.js
       |-> cadidatos
             |-> model.js
             |-> schemas.js
             |-> routes.js
             |-> handlers.js
       |-> ...
| -> tests
       |-> fixtures
             |-> candidatos.js
             |-> ...
       |-> specs
             |-> candidatos.js
             |-> partidos.js
             |-> ...
dalssoft commented 8 years ago

Coloquei na wiki do projeto: https://github.com/codeforsaopaulo/assimfalouocandidato/wiki/Arquitetura:-Vis%C3%A3o-Geral

dalssoft commented 8 years ago

@mvcds

Se separarmos o ID do candidato da numeração TSE/TRE, teremos uma tabela para pessoa, o que permite que candidatos tenham numeração variada (se a mesma for alterada conforme partido, posição almejada, ano da eleição, etc).

pensei em manter o banco de dados integro para aquela eleição e não para muitas eleições, para manter o mais simples possível

A tabela de candidatura é uma tabela auxiliar só para mostrar o cargo? Se for isso, acho melhor mudarmos o nome para TipoCandidatura. Pra mim, Candidatura implica partido, tipo, ano e possiveis outras informações.

fiquei na dúvida também, mas preferi deixar uma tabela para ficar bem didático para quem for dar manutenção (ao invés de usar alguma feature do banco para manter integridade)

Adicionar o número do partidos seria legal.

done

Como temos funcionalidades ligadas à cargos/funções, acho que temos que armazenar esses dados para montar um histórico. Vamos precisas deixar na nossa base quais projetos cada candidato entregou ou iremos ficar buscando essa informação de forma semelhante aos posts? No caso de ser "estático" precisaremos de uma tabela pra esses dados também.

pelo o que entendi ficou decidido que na nossa página teria links para páginas parceiras ou públicas que teriam esse conteúdo, certo?

Se entendi a proposta da seed, é preencher o banco com dados pré-definidos. Pode ser uma boa ideia para um momento futuro, mas enquanto estamos em concepção podemos usar algo como o rosie junto ao faker, para criarmos algo que se assemelha aos modelos. O problema dessa abordagem é que são dados falsos, mas podemos começar a testar a modelagem com eles antes de inserir dados reais.

a ideia é ter uma forma rápida de alimentar com dados reais os dados dos candidatos. algo que seja fácil das pessoas colaborarem também. pensei num arquivo de seed, que é fácil de editar via github direto.

podemos usar o faker para teste, mas ai é outra coisa.

@danielbdias

O único comentário sobre ela é que eu sugiro termos ids separados dos ids dos órgãos governamentais (o caso das tabelas candidato e partido).

done

dalssoft commented 8 years ago

@alanhoff se separarmos a parte de business da infra, a API e Web (site) são só apresentação do mesmo dado e lógica.

indo nessa linha, sugiro a estrutura do nodebase, que fica claro o papel de business (models, repositórios, etc) e o que é camada de visualização/interação (infra\service, infra\web, infra...)

mas confesso que no final tenho pouco apego à estrutura do projeto. fica o que o pessoal achar melhor.