Regra de negócio e Banco de dados em um Sistema Distribuído

Programação Arquitetura
#1

Pessoal.

Estamos em um projeto grande de reestruturação de uma empresa que começou com uma filial e hoje tem 5 espalhadas pelo Brasil.

A cenário é o seguinte:

-Cada filial ainda contém regras de negócios diferenciadas (e acho que não vai mudar muito)
-Cada filial transita o mesmo tipo de Objeto (Ajuda para declarar entidades e modelar o Banco “novo”)
-A modelagem do banco de dados foi moldada não da melhor forma para cada filial, criando ambientes no máximo “parecidos”

Pensamos em centralizar tudo na Matriz em São Paulo (Servidor de Banco, Servidor Web, AD, Aplicação e tudo mais)

Porém temos muitas dúvidas ainda em questão de performance e disponibilidade. Nossos links de comunicação com o Sul e Norte são MPLS de 2Mb sendo um deles bem instavel. Temos perspectiva de crescimento (leia-se anexar novas filiais). Como nós trabalhamos hoje com banco de dados locais e sistemas clients não temos a noção de quanto ganharemos ou perderemos em relação à isso.

Duvidas:

Como organizar as regras de negócio utilizando reuso de código e generalizando o que for comum? Classe abstrata? Enum? Interface?
É realmente viável com nossa infra de dados brasileira centralizar em um DataCenter (ou na nuvem)?
Replicação de dados é viável?

#2

em relação a regra de negocio,

se vc tiver o msm banco em todas filiais, acho que uma ideia bacana seria a utilização de um motor de regras, como o Drools, pois vc pode fazer uma unica aplicação e em cada filial, fazer uma regra de negocio especifica.

espero ter te ajudado.

t+

#3

Eae alissonvla!

Acredito que a qualidade do link vai impactar bastante a percepção do desempenho da aplicação pelos usuários.
Acho que a aplicação centralizada vai ajudar na organização em geral.

Vale a pena testar dois cenários de acesso pra ver qual fica mais “leve”:

  • Aplicações distribuídas com banco de dados centralizado.
  • Aplicação única, mas com acesso das filiais via web mesmo.

Falows t+

#4

Centralizar ou distribuir, sempre possuem prós e contras.

Se você centralizar, seria bom isolar o que muda dessas regras de negócio e mantê-las no cliente; o que é estável fica centralizado. Web service atende bem se você não tiver um tráfego de dados massivo (uma quantidade muito grande e granular). Já do lado cliente, você poderia ter uma aplicação Java que tendo algumas regras de negócio que são específicas da filial OU, como já foi dito, joga tudo quanto é regra de negócio na central, e as regras de negócio mais “volatéis” ficariam no Drools (nesse caso o cliente poderia ser somente um navegador mesmo), a penalidade da segunda abordagem é a complexidade, e da primeira o manter do código e a distribuíção da aplicação.

Se essa centralização será em um datacenter, vai depender de como é a estrutura da empresa em SP - sai mais barato manter uma estrutura dessas in-house ou comprar a infra de uma empresa especializada (tipo UOL Host, Locaweb)? Provavelmente comprar de uma estrutura de terceiro será melhor por uma porção de fatores como um link de comunicação mais estável e veloz, redundância de servidor, redundância no fornecimento de energia, suporte especializado, backups.

Com relação a performance e disponibilidade, acredito que isso está muito mais ligado a infra-estrutura do que ao software em si. Tentar resolver problemas de infra, no software, é uma desgraça. E muita gente pensa que isso é qualidade de software, mas nem sempre, gastar R$ 50.000,00 a mais de desenvolvimento não parece melhor que pagar um link R$ 700,00 mais caro (isso é só um exemplo).

Replicar dados é muito ruin, já tive más experiências com aplicações assim, a menos que tenha uma boa conectividade; mas se tem um boa conectividade porque replicar dados não é verdade? Seria mais fácil acessá-los diretamente no banco. Porém, replicar dados tem uma vantagem, trabalhar off-line, e no seu caso, onde a infra-estrutura não será muito confiável, isso seria bom.

#5

Bem, galera.

Não respondi ou postei nada pois testamos o Drools (que até então era desconhecido… Muito bom por sinal), e estamos tendo uma guerra de culturas aqui na empresa. A cultura que está fundamentada é que o servidor NECESSITA estar em uma das filiais:

  • Manter dados fora da empresa é arriscado…

Pois bem, ainda deixo em aberto para outras sugestões e opiniões.

#6