Publicado em Arquiteto

Microservices é bom? Nãooo…é ruim

Sem título

Até que enfim achei um post falando disso e fico feliz em saber que não é só eu que percebi isso. Microservice não é uma coisa boa! Microservice é uma coisa ruim! Microservice é como se fosse uma ultima atitude arquitetural desesperada para tentar arrumar e organizar uma solução monolítica que chegou ao caos por ser muito grande e complexa de gerenciar. A introdução dessa arquitetura em si já gera muitos problemas e contornos que se forem aplicadas para soluções sem perfil acabam só estragando ao invés de melhorar. Por isso amigo, cuidado como as frescuras e modismo de fazer as coisas sem a necessidade! T+

“Pois o Espírito que Deus nos deu não nos torna medrosos; pelo contrário, o Espírito nos enche de poder e de amor e nos torna prudentes.” 2 Timóteo 1:7

Publicado em Arquiteto, NoSQL

NoSQL Como armazenar os dados de uma aplicação moderna

QJqAPTPE3N1YMoK32lk4dVw2XtfE6jmYTk-u1SahDYE_largeEste livro se destina a desenvolvedores e arquitetos de software que já tenham experiência com algum tipo de banco de dados relacional ou NoSQL e querem aprender mais sobre os tipos de bancos de dados e entender os impactos que a escolha deles pode trazer para sua arquitetura e seus clientes.

No decorrer do livro, quando um novo conceito ou funcionalidade é apresentado, normalmente existe a comparação com os bancos relacionais e o SQL. Então, ter um conhecimento prévio sobre conceitos básicos de bancos de dados, como tabelas, joins, forma normal (normalização de dados) e um pouco de SQL, ajudará muito o entendimento.

Apesar de o livro abordar exercícios práticos de programação, ele foca totalmente na camada de persistência, com alguns exemplos de código em JavaScript, erlang, bash, e algumas query languages. Por isso, não existe a necessidade de conhecer bem alguma linguagem de programação específica, nem mesmo as utilizadas, mas é importante ter noções de programação para compreender e reproduzir os códigos apresentados.

A maior parte das tecnologias apresentadas pode ser instalada em Windows, Mac ou Linux, e todas elas possuem imagens prontas para rodar em docker containers. Apesar da preferência por ambientes baseados em Unix, é possível reproduzir quase todos os exercícios em qualquer sistema operacional.

“Por último, meus irmãos, encham a mente de vocês com tudo o que é bom e merece elogios, isto é, tudo o que é verdadeiro, digno, correto, puro, agradável e decente.” Filipenses 4:8

Publicado em Arquiteto

Arquitetura de Software – Organização em Camadas com Java 9

onionNa arquitetura de software, a divisão em camadas é umas das principais estratégias de organização da estrutura de um futuro software. Uma das dúvidas bem frequentes no nosso curso de arquitetura é como na prática fazer tal operação. A dica de hoje é uma explicação bem completa de como fazermos isso usando Java:

1. Separação por Pacotes

Em projetos de pequeno e médio porte é muito comum separarmos as camadas da solução em simples pacotes, no qual cada pacote estabelece o limite de cada camada. É a forma mais básica e fácil de fazer. Sempre inicie um projeto fazendo isso.

2. Separação por Projetos

Acontece quando você começa separando as camadas em pacotes mas chega um ponto do projeto que as camadas começam a ficar muito grandes, os pacotes passam a se tornar”gordinhos” e o projeto começa a pesar. É nesse  ponto que precisamos parar e melhorar. Assim, refatoramos cada camada para um projeto separado, movendo todos os recursos e testes para dentro de projetos individuais. Teríamos um projeto para GUI, Regras de Negócio, Relatórios, Persistência e etc. Cada projeto passa então a gerar um JAR que corresponde aquela determinada camada que é integrado ao projeto principal, normalmente o projeto que implementa a camada de GUI. Nesse ambiente, é necessario o uso de ferramentas de gerenciamento de dependências como Maven ou Gradle para geração dos jar, amarração de dependência e build do software final.

3. Separação por Contextos de Negócio

Quando um projeto começa a fica muito grande, mesmo com a divisão de camadas por projetos separados, algumas camadas podem se tornar muito grandes ao longo do tempo. É ai que uma camada/projeto pode ser divido em contextos de negócios. É o que chamamos de Bounded Context. Veja nesse link uma breve explicação. É exatamente aqui que começa o assunto de microservices, no qual você tem a opção de fazer deploy de cada camada ou contexto de negocio em servidores separados. E assim, você passa a dividir cada camada em contextos individuais , gerando seus respectivos jar’s da mesma forma que na opção 2 ou fazendo uso da estratégia de microservices.

4. Separação por Módulos Java 9

Com a o lançamento do Java 9, teremos mais uma opção agora fundamentada na especificação  Java que são os módulos. Nessa opção, cada camada ou contextos de negócios da solução poderá ser organizada em um módulos declarando seus limites, classes expostas e dependências internas. Depois do lançamento seria o opção mais indicada. Lembrando que mesmo usando o módulos, ainda sim podemos fazer dentro de um mesmo projeto ou em projetos separados.

Você gostaria de aprender mais sobre o assunto? Faça nosso curso de Introdução a Arquitetura de Software com Java. Estarei la para te atender🙂 !

“Quem teme o SENHOR e é humilde consegue riqueza, prestígio e vida longa.” Provérbios 22:4

Publicado em Arquiteto

Arquitetura – Ten Coding Guidelines in Practice.

Real_World_Maintainable_Software_frontA indústria de desenvolvimento de software esta cada vez mais percebendo que o sucesso de um projeto depende da viabilidade a longo prazo. Para ajudar nesse esforço, a SIG identificou dez orientações para a entrega de código que é fácil de manter e adaptar-se ao longo do tempo. Veja nesse e-book grátis! Gostaria de aprender  mais sobre esse assunto? Veja nosso curso de AQT M1 – Introdução a Arquitetura de Software e saiba como criar um projeto sustentável.

“Tu és o meu esconderijo e o meu escudo; eu ponho a minha esperança na tua promessa.” Salmos 119:114

Publicado em Arquiteto

DBeaver – Conecte em todos os seus bancos de dados relacionais e nosql

beaver-headVocê já ficou cansado de entupir e estragar sua maquina por ter que instalar 1 ferramenta de administração para cada banco de dados diferente? SQLServer + MySQL + MongoDB? Eu já fiquei e muito ainda!!!

Resolva seu problema com usando o DBeaver – http://dbeaver.jkiss.org, ferramenta simples, de graça, feita em java, baseada no eclipse, usa maven para baixar os driver e muito fácil de usar. Ufaaaaa……acabou o terror!

Free multi-platform database tool for developers, SQL programmers, database administrators and analysts. Supports all popular databases: MySQL, PostgreSQL, SQLite, Oracle, DB2, SQL Server, Sybase, Teradata, MongoDB, Cassandra, Redis, etc.

“A luz brilha na escuridão, e a escuridão não conseguiu apagá-la.” João 1:5

Publicado em Arquiteto

Livro Grátis – Software Architecture Patterns

catO sucesso de qualquer desenvolvimento de software depende também de um bom padrão de arquitetura. Ao descrever as características gerais da arquitetura, esses padrões não só orientam os designers e desenvolvedores sobre como componentes, mas também determinar as maneiras pelas quais esses componentes devem interagir. Veja nesse livro um mergulho profundo em muitos padrões de arquitetura de software comum. Cada padrão inclui uma explicação completa de como ele funciona, explica os benefícios, considerações do padrão, e descreve as circunstâncias e condições que se destinava a resolver. O livro também inclui uma análise e scorecard para cada padrão com base em vários arquitetura de software e atributos de qualidade de desenvolvimento. O livro é grátis e pode ser baixado nesse link. Bons estudos🙂 !

“Assim já não sou eu quem vive, mas Cristo é quem vive em mim. E esta vida que vivo agora, eu a vivo pela fé no Filho de Deus, que me amou e se deu a si mesmo por mim.” Gálatas 2:20

Publicado em Arquiteto

Plano de Evolução – Nível de Qualidade Equipe Java

imagesEm uma das empresas que eu atuo como consultor, eu acabei construindo uma classificação que define o nível de qualidade da solução produzida por uma equipe de desenvolvimento Java. Esse plano foi utilizado para conscientizar qual era a real situação da qualidade do código produzido pela corporação e principalmente para traçar um plano de evolução para cada programador da equipem utilizado no conceito “de pronto” do Scrum. Hoje eu gostaria de publicar o plano com objetivo de receber sugestões sobre o assunto. Segue abaixo:

Nível 0

É classificada como “nível 0” uma equipe de desenvolvimento que codifica suas soluções Java sem nenhuma práticas, diretrizes ou patamar qualidade estabelecido, deixando o fato de livre decisão a cada desenvolvedor.

Nível 1

É classificada como “nível 1” uma equipe de desenvolvimento que consegue codificar suas soluções Java compatível com as seguintes práticas:

  1. Java Code Convention – o código da solução é escrito seguindo o padrão mundial de organização e nomeação dos elementos de programação.
  2. Java Doc – o design da solução é 100% documentada ao mesmo tempo em que é desenvolvida.

Nível 2

É classificada como “nível 2” uma equipe de desenvolvimento que consegue codificar suas soluções Java seguindo as práticas descritas no “nível 1”, acrescidas simultaneamente das novas seguintes práticas:

  1. Java Efetivo – o código da solução contempla o uso correto dos idiomas de programação Java descrito pelo Joshua Bloch em seu livro Java Effective.

Nível 3

É classificada como “nível 3” uma equipe de desenvolvimento que consegue codificar suas soluções Java seguindo as práticas descritas no “nível 1 + 2”, acrescidas simultaneamente das novas seguintes práticas:

  1. TDD – o código da solução é escrito seguindo o a filosofia baseada em testes, criando na solução algum nível de cobertura de testes automatizados.

Nível 4

É classificada como “nível 4” uma equipe de desenvolvimento que consegue codificar suas soluções Java seguindo as práticas descritas no “nível 1 + 2 + 3”, acrescidas simultaneamente das novas seguintes práticas:

  1. Princípios OOP – o código da solução contempla o uso de princípios básicos e elementares da programação orientado a objetos.
  2. Padrões de Projeto – o código da solução contempla o uso correto de padrões de projeto.

Nível 5

É classificada como “nível 5” uma equipe de desenvolvimento que consegue codificar suas soluções Java seguindo as práticas descritas no “nível 1 + 2 + 3 + 4”, acrescidas simultaneamente das novas seguintes práticas:

  1. Refatoração – o código da solução contempla o uso correto dos princípios de refatoração de programação Java descrito pelo Martin Folwer.
  2. Programação pareada – o código da solução é aperfeiçoada com a refatoração utilizando a pratica de programação em par.

Nível 6

É classificada como “nível 6” uma equipe de desenvolvimento que consegue codificar suas soluções Java seguindo as práticas descritas no “nível 1 + 2 + 3 + 4 + 5”, acrescidas simultaneamente das novas seguintes práticas:

  1. Desenvolvedor Oracle Certified OCA e OCP – o código da solução contempla o uso adequado dos recursos básicos de programação e API JSE resultantes do conhecimento adquirido pela processo de certificação oficial Java.

Dicas

Scrum Masters, gerentes XP ou GP responsáveis pelas equipes podem utilizar estes níveis de qualidade para propor uma plano de evolução individual a cada membro desenvolvedor. Vale lembrar que os níveis são cronologicamente evoluídos. Desafie sua equipe e veja como eles podem construir uma solução Java com o mais alto padrão de qualidade. Só que já passou por isso é que pode realmente saber da diferença da entrega e manutenção de uma solução baseado no nível da equipe. E você? Em que nível você se encontra?

Disse Jesus: “Nem ele nem seus pais pecaram, mas isto aconteceu para que a obra de Deus se manifestasse na vida dele”. João 9:3

Publicado em Arquiteto

Microservices = Sistemas grandes e complexos

virgula-mulher-duvidaA arquitetura monolítica é um padrão comumente usado para o desenvolvimento de aplicações corporativas. Esse padrão funciona razoavelmente bem para pequenas aplicações, pois o desenvolvimento, testes e implantação de pequenas aplicações monolíticas é relativamente simples. No entanto, para aplicações GRANNNNDESSS E COMPLEXAAASSSSSSSSS, a arquitetura monolítica torna-se um obstáculo ao desenvolvimento e implantação, dificulta a utilização de uma entrega contínua, além de limitar a adoção de novas tecnologias. Para grandes aplicações, faz mais sentido usar uma arquitetura de microservices, que divide a aplicação em um conjunto de serviços.

Acho que tem gente que ainda não entendeu o x dessa questão. Eu ando vendo por ai gente fazendo microservices com meia duzia de classes, entrando em um buraco tão grande problemas resultantes dessa nova abordagem sem nenhuma necessidade. Quando você usa microservices sem precisar, você acaba ganhando de brinde tantos problemas extras, que tem gente passando mais tempo resolvendo eles do que usufruindo dos benefícios dessa nova abordagem arquitetural. Mais uma vez, o modismo e os artigos das revistas tem influênciado os leitores erradamente.

“Eu lhes dou este novo mandamento: amem uns aos outros. Assim como eu os amei, amem também uns aos outros.” João 13:34

Publicado em Arquiteto

Diagramação

2image02

Draw.io é uma ferramenta de diagramação gratuita disponível para desktop como um plugin para o navegador da Google Chrome ou para uso de forma online desenvolvido pela JGraph. Com o draw.io é possível, de forma simples e rápida, criar uma grande variedade de diagramas, como por exemplo: diagramas de fluxo de dados, diagramas de rede, diagramas UML, mapas mentais, diagramas de BPMN entre outros. Outra facilidade que esta ferramenta possui é a de integração com Dropbox, OneDrive e Google Drive, para armazenamento dos diagramas criados. Além disso, o draw.io pode ser integrado com as ferramentas da Atlassian como Jira e Confluence. Existem vários tutoriais no site do draw.io para os primeiros passos. Até a próxima!

“Eu afirmo a vocês que isto é verdade: quem ouve as minhas palavras e crê naquele que me enviou tem a vida eterna e não será julgado, mas já passou da morte para a vida.” João 5:24

Publicado em Arquiteto, Frameworks Effective

Saia do Java Boilerplate

DontRepeatYourself

Você já se cansou de fazer get’s, set’s, equals, hashCode, toString e objetos imutáveis para suas classes Java? Eu já! Segue aqui algumas opções de frameworks que resolvem essas repetições:

Outra opção é mudar de linguagem, eu mesmo uso Groovy. Bons estudos para todos!

“Portanto, deixem todo costume imoral e toda má conduta. Aceitem com humildade a mensagem que Deus planta no coração de vocês, a qual pode salvá-los.” Tiago 1:21