e conseguir informacao hoje, e como beber agua de um hidrante. Tentarei modularizar o assunto, falando de uma estrutura macro aqui, e posteriormente entrando em detalhes de cada modulo.Apos quase 20 anos de desenvolvimento, eu ja trabalhei com sistemas estruturados das mais diversas maneiras, e ja criei meus proprios sistemas(muitos). O legal disto e voce ter a experiencia falando a seu favor, e na maioria das vezes o que eu percebo e que o mercado nao usa o que e o melhor, mas o que esta mais rentavel ( para quem ? ).Muitas vezes um fornecedor de um produto convence um cliente que o produto e bom (mesmo que nao seja) e o cliente compra o produto, paga caro, e exige que isto seja usado, mesmo nao sendo a melhor (ou sequer uma boa) opcao.Desenvolvedores sao criados/educados nestes cenarios, e passam pelo treinamento destes fornecedores, que fazer uma especie de "lavagem cerebral", ensinando centenas de "padroes" e "boas praticas".Em minha opiniao, o melhor seria um sistema totalmente desacoplado, onde nao importa qual a tecnologia dos outros modulos. Quem trabalha com terminais de linha de comando, sabe que funciona muito bem a transparencia tecnologica neste contexto. Nao importa qual tecnologia utilizada, eu tenho um protocolo para chamar um comando e uma resposta padrao. Eu tenho stdin, stdout e stderr sempre... Eu tenho codigo de retorno para me informar do sucesso ou nao do comando... Pipes, etc.Pesquisando para este artigo, encontrei uma boa referencia deste conceito:https://staticapps.org/articles/why-build-static-apps/Seria algo como:webapp - Modulo Web Estatico, renderizado do lado do cliente(browser) com o uso de javascript/css, com o unico controle do lado do servidor sendo o acesso de recursos restritos a autenticacao valida. Todo acesso a informacoes para geracao dinamica de conteudo, deveria ser requerido via requisicoes Ajax(XHR) REST ao modulo webapp-api. Pode ser considerado 3 tipos de comunicacao: REST, WebSockets e "Push Notifications". Nenhuma outra interface alem da webapp-api deve ser chamada.webapp-api - Modulo Rest para prover dados ao modulo webapp. Usando principalmente comunicacoes REST(JSON) permitindo um desacoplamento total e independencia de plataforma usada no servidor, tambem pode prover Push Notifications e WebSockets. Sempre stateless (independente de sessao), recebendo token de autenticacao sempre que necessario, usando SSL. Este modulo devera ter acesso a um outro componente centralizador de informacoes se sessao session-api para permitir escalabilidade, e ao componente de acesso aos dados, data-module.session-api - Tratar sessao e um problema complicado em escalabilidade, recomendo topicos em mensageria (MQ), por exemplo o Apache ActiveMQ: (http://activemq.apache.org/). Desta forma, voce podera ter redundancia em seu controle de sessao, garantindo uma melhor escalabilidade.data-module - Para escalabilidade, aqui costuma ser o maior gargalo, normalmente nao queremos overhead no gerenciamento de dados. Mas mesmo aqui, penso que mensageria deveria ser considerada como uma opcao valida da mesma forma que no componente session-api. Tenho experiencia onde a camada de dados foi substituida com sucesso por mensageria, antendendo picos de transacoes superiores a 800tps. Isto ja e muito, mas alem disto, esta estrutura facilita acoes para ampliar este poder de processamento distribuido.Esta separacao permite substituir qualquer camada por mocks para criacao e execucao testes unitarios, de