Publicado em Arquiteto

Design Patterns – SourceMaking

abstract_factory_example1-2xNa engenharia de software, um padrão de projeto é uma solução repetível geral para um problema que ocorre comumente em design de software. Um padrão de design não é um projeto acabado que pode ser transformado diretamente em código. É uma descrição ou modelo de como resolver um problema que pode ser utilizada em muitas situações diferentes.

Confesso que mesmo lendo vários livros sobre esse assunto, foi nesse site chamado de sourcemaking que eu encontrei a melhor documentação, os melhores gráficos e explicações sobre design patterns. Leitura obrigatória para os projetistas e arquitetos de software! t+

“O Senhor não demora a fazer o que prometeu, como alguns pensam.” 2 Pedro 3:9

Publicado em Arquiteto

Desabafo Total

professor burroEu não costumo postar textos negativos e nem falar mal de “pessoas”, mas hoje eu vou sair da minha ética profissional e vou “chutar o pau da barraca”. Tenho passado por situações que eu realmente não entendo, como tem no mercado profissionais desinformados, usando tecnologia de forma totalmente errada. Segue os casos:

Usar SOAP para retornar uma String contendo um XML…

Como pode??? SOAP é um protocolo pesadíssimo com o objetivo de determinar e garantir um “contrato” de envio e recebimento de objetos no formato XML no qual faz parte do contrato o esquema e a validação do próprio envelope do objeto. Declarar um WSDL com retorno de String e colocar um XML la dentro só pode ser coisa de manézãooooo mesmo!! Não faz nenhum sentido isso!! Meu Deus do céu!!! Peguei + de 3 empresas grandes fazendo isso e ainda tiver que ler e transformar o xml via String!!

Usar MongoDB como se fosse relacional….

Tem gente copiando modelo relacional para dentro do MongoDB, usando referencia de ID’s em diferentes collections, criando processos compostos “transacionais” manuais, implementando roolback manuais e um trilhão de porcaria de código para suprimir as buscas com JOIN. Meu Deuuusss do céuuu!! Volta para o banco de dados relacional cabeçudooooo! MongoDB não foi feito para isso….La no mongo você desnormaliza os dados, cria uma única collection por transação e persiste somente 1 objeto único atômico com todos os seus agregados por transação de sistema. Você esta querendo economizar espaço? Pra que? Não ta usando um NoSQL para escalar horizontalmente? kkkkkkk…….É verdade que o mongo tem recursos para fazer joins entre collection, mas é para ser usada na exceção e não como regra.

Usar microservices para meia duzia de serviços…

Microservice não é uma coisa boa! Microservice é uma coisa ruim! Microservice é como se fosse uma última 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. Para de abelhuuudarrrrr !! Fazer soluções pequenas usando microservices vai mais gerar problemas que o próprio contexto de negócio da solução!  Arquitetura monolítica sempre sera para 90% dos casos….

Ufa…agora estou mais leve! E desde já, me perdoem pelo desabafo….

Publicado em Arquiteto

Livro Building Maintainable Software – Java Edition

lrgVocê já se sentiu frustrado, quando trabalhou com código de outra pessoa? O código fonte de uma solução é difícil de manter e é o grande problema no desenvolvimento de software de hoje, levando a atrasos onerosos e defeitos constantes. Seja parte da solução! Veja neste livro: Building Maintainable Software, Java Edition 10 diretrizes a ser seguidas para a entrega de um software Java que seja fácil de manter e adaptar-se. Estas orientações foram derivadas da análise de centenas de sistemas do mundo real.

Para você que deseja realmente aprender tais conceitos, veja nosso curso de Introdução a Arquitetura de Software que cobre os mesmos princípios arquiteturais.

“Procurem ter paz com todos e se esforcem para viver uma vida completamente dedicada ao Senhor, pois sem isso ninguém o verá.” Hebreus 12:14

Publicado em Arquiteto

SourceMaking – Um site muito informativo e divertido

Sem título“Eu sou o SourceMaking. Vou contar-lhes muitas histórias sobre boa arquitetura de software e ensiná-lo a usar bons padrões de design. Vou guiá-lo através de anti-padrões, armadilhas e erros comuns que as pessoas fazem quando planejam, criam e gerenciam projetos de software. No final, eu vou ensiná-lo a sentir cheiro de código ruim e melhorá-lo com refatoração.”

Dias atras eu acabei descobrindo esse site https://sourcemaking.com que ensina de forma muito didática e divertida a respeito de padrões de projeto e anti- patterns em geral. De todos os livros que eu já li, esse site incrivelmente foi a que fez explicações e imagens altamente fáceis, didáticas e intuitivas a respeito de todos esses assuntos. Leitura obrigatória para todos os arquitetos de plantão! Um ótimo final de semana😉 .

“Mas o Senhor Jesus é fiel. Ele lhes dará forças e os livrará do Maligno.” 2 Tessalonicenses 3:3

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