Olá pessoal, gostaria de pedir a ajuda de vcs e troca de conhecimento.
Eu gostaria de saber se alguém já viu ou tem alguma ideia de como construir uma
Arquitetura em módulos separados ( DETALHE ) nenhum programador tem acesso a todo o
Código do projeto.
Como separar dessa forma e ter um build (ok).
isso existe desde 1900 e guaraná com rolha na integração entre sistemas.
quando alguem desenvolve um sistema que acessa um banco de dados, vc tem exatamente este problema ( afinal vc não tem acesso ao codigo do driver do banco ou ao banco em si, nem acesso ao codigo do browser que vc esta usando, nem o codigo da pilha tcp/ip, etc )
o que vc precisa é definir a interface entre os modulos e ter uma implementação de referencia do mesmo.
um bom exemplo são:
I. sistemas que interagem via interface REST.
imagine dois sistemas, A e B, onde A conecta em B e pede algo via GET ( simples )
agora imagine um projeto chamado ReferenciaB ( vamos chamar de RB ) onde tanto A quanto B dependem para os testes.
A vai usar RB para simular uma serie de requests ( quando retorna sucesso, quando retorna fracasso, etc )
B vai usar RB para testar se a dada serie de requests realmente retorna o esperado.
II. sistemas baseados em especificação
nesse caso B pode não fornecer RB mas ele fornece uma documentação e vc implementa os testes baseado no documento.
III. sistemas baseados em especificação com acesso ao codigo compilado
uma vez eu implementei um cliente para Riak ( banco de dados NoSQL ) usando a API Protocol Buffers.
meus testes unitarios foram baseados na especificação ( se o tipo do request for x, retorna esses bytes )
e tinha testes funcionais onde eu realmente usava uma versão REAL do Riak, enviando e lendo bytes.
nesse caso eu não tinha acesso ao codigo. e nem precisava pq a minha interface era a API Publica, eu tinha especificação e eu tinha como fazer testes com o meu alvo.
ok dei exemplos de HTTP/Sockets mas uma API publica entre modulos segue o mesmo principio. se vc usa bons principios de injeção de dependencias vc pode mockar o resto do codigo que vc não tem.
portanto vc tem opções:
nada impede que os testes do codigo de um modulo use, por exemplo, o .jar de outro modulo, em uma fase de testes de integração
nada impede que seja criados testes que verifiquem a integração de cada modulo isolado
nada impede de juntar tudo e rodar uma bateria de testes ( se o sistema é grande, vc pode rodar nightly tests quando vc pega tudo o que ja foi feito naquele dia e roda junto durante a noite ).
Perceba que vc pode ter um build ok mas um codigo que não funciona pq não integra direito. Afinal um build é diferente de uma release.
O que vc quer é uma release adequada. e pra isso vc precisa de testes unitarios e de integração. não tem almoço gratis.
Pec Obrigado pela resposta.
É de se imaginar que ao ter uma separação envolvendo um projeto, não seria possível a geração do artefato deste projeto de forma separada.
Eu gostaria de uma solução que trate isso, eu conheço estas formas
citadas no entanto acaba que tudo isso fica nas mãos de um desenvolvedor para realizar a codificação.
Agora um modelo , conceito ou solução que trate isso de forma bem
gerenciável isso que estou em busca.
O modelo de documentação baseando por Ex: em REST tratando a integração por meio de uma documentação especifica não me atente, sendo que eu preciso é justamente dessa parte de construção do lado do REST por assim dizer…
O modelo de acesso a um interface de código compilado é interessante e no momento minha melhor opção, por eu tenho um desvantagem de muitas dependências de 3party e alguma forma de comunicação por interface EX: RMI, EJB
A minha solução até o momento é , trabalhar com interfaces que determinem as regras de implementação juntamente com os objetos de domínio, sendo estes expostos em um artefato compilado, para então minimizar ao máximo quebras de integração.
Os contratos se implementações e objetos de domínio serão então divididos entre 3 desenvolvedores que terão como tarefa suas implementações.
E no final o fechamento o restante dos contratos de Interface seriam definidos para apenas 1 desenvolvedor fazer o fechamento do artefato.
Nel,
MicroSeviços é uma boa, o grande problema é obedecer todos as regras para sua implementação, quando se trata de uma equipe que não tem domínio desta metodologia.
Você não precisa olhar o conceito completo de microserviços e implementar cada detalhe dele. Veja o conceito e o que dentro dele atenderia você. A ideia é uma arquitetura separada, não é? Então, tu tem serviços distintos que realizam (ou não) a comunicação entre si, pronto.
Se serão serviços pequenos e objetivos ou mais abrangentes, aí fica a teu critério, mas a ideia por trás do microserviço é essa (de forma superficial).
por que não? coisa mais comum é vc adicionar as dependencias usando arquivos jar, por exemplo.
isso é mais uma questão de como vc vai empacotar o sistema.
[quote=“E.Silva, post:4, topic:340715”]
Eu gostaria de uma solução que trate isso, eu conheço estas formascitadas no entanto acaba que tudo isso fica nas mãos de um desenvolvedor para realizar a codificação.
Agora um modelo , conceito ou solução que trate isso de forma bem
gerenciável isso que estou em busca.[/quote]
eu não entendi nada do que vc falou.
seu problema é como distribuir um projeto para N desenvolvedores para que eles possam trabalhar em paralelo com minimo ou 0 dependencias?
se sim, qual a razão disso?
Razão principal -> Segurança
Seria segurança contra quem?
nao vejo como segurança se aplica aqui. Serio…
Exemplo:
Uma Empresa(Cliente) contrata 7 Empresas(Development) para desenvolver seu Produto!
Regra de Segurança para o negócio da Empresa é simples ( Nenhuma Empresa de desenvolvimento pode ter acesso ao Código Completo ) .
Agora acho que podemos ver Segurança!
Um sistema de gerenciamento de código fonte já não atende ao que você precisa? Cada time terá acesso ao módulo ou sub sistema que for permitido.
Agora, cá entre nós, 1 empresa terceira já é complicado, imagina o caos que deve ser 7 empresas desenvolvendo um produto.
Acho que ele quer dizer que esta terceirizando o serviço e não tem como garantir que os contratados seguem alguma metodologia ou possuem conhecimento sobre microservices. Neste caso o ideal seria uma ferramenta que ele possa instalar e que alerte o usuário quando a segurança estiver comprometida.