Archive | Arquiteto RSS for this section

Como se transformar em um arquiteto de software? V2

images

Estes dias atras me perguntaram quais seriam as informações mais básicas para se tornar um arquiteto de software. Segue ai a resposta bem resumida:

1)Modelo C4

Para o plano arquitetural conhecido como “blueprint” de um projeto, se faz necessário projetar a solução usando diagramas. Esqueça a UML! Eu uso modelo chamado de “C4”. Aprenda no livro Software Architecture for Developers.

2)Projeto e Design DDD

Para o design de camadas e projeto oop, se faz necessário uma abordagem 100% OO. Eu uso uma técnica chamada a de “Domain Driven Design”. Aprenda no livro Domain-Driven Design: Atacando as Complexidades no Coração do Software.

3)Desenvolvimento TDD

Para o desenvolvimento, se faz necessário usar uma abordagem de construção de software. Eu uso uma técnica chamada de “Test Driven Design”. Aprenda no livro Test-Driven Development – Teste e Design no Mundo Real.

4)Design Emergente

Para criação e evolução da estrutura do produto em desenvolvimento, se faz necessário o uso de alguma abordagem. Eu uso uma chama de”Design Emergent”. Aprenda no livro Emergent Design: The Evolutionary Nature of Professional Software Development.

5)Linguagem Dinâmica

Para programação oo, use uma linguagem de programação dinâmica no qual se possa usufruir de técnicas como metaprogramming e duck type. Eu uso Groovy, aprenda no livro Programming Groovy 2: Dynamic Productivity for the Java Developer. Um arquiteto nos dias atuais deve saber quando dosar estruturas com Design By Contract versus Design By Capabilities.

Eu me coloco a total disposição para ajudar e resolver duvidas de qualquer um interessado em trilhar esse caminho. Se você precisar de uma ajuda extra e tem interesse em investir em cursos, nossa grade de arquitetura cobre a maioria desses tópicos AQT M1, M2 e M3. Bons estudos!!!.

“Mas, em todas estas coisas somos mais que vencedores, por meio daquele que nos amou.” Romanos 8:37

Guide to Enterprise Integration

unnamed
Faça donwload do Guia DZone para Enterprise Integration de 2015 que investiga novas tendências no cenário de integração e como esses novos padrões e tecnologias podem ajudar a reduzir as dificuldades de integração. Abrange microservices, SOA, plataformas de integração em nuvem, comunicações RESTful e como superar os problemas com sistemas distribuídos.

“enquanto aguardamos a bendita esperança: a gloriosa manifestação de nosso grande Deus e Salvador, Jesus Cristo.” Tito 2:13

Arquiteto Java – Spring Framework

spring1Mesmo depois dos avançados das ultimas especificação do JEE , vemos que ela ainda esta muito longe de se igualar as opções oferecidas pela plataforma Spring. Vale a pena lembrar que da mesma forma que as especificações vão melhorando ao longo do tempo, o Spring também vai evoluindo em uma velocidade muito mais rápida e ampla, uma vez que não depende de nenhum tipo de votação comunitária.

Eu mesmo ao longo dos meus 15 anos de experiência, sempre tive a cautela de preferir produtos JCP ao invés de proprietários, visando o grande ideal da portabilidade e a independência de vendor, mas na prática percebo que ao longo do tempo tenho adotado os produtos Spring mais e mais. Motivo? O mesmo pelo qual o Spring foi criado: ser uma opção muito mais rápida, barata e leve de um lightweight container que ofereça serviços plugáveis de infraestrutura para soluções corporativas com a mesma qualidade.

Hoje a minha dica é sobre os principais livros de Spring atualizados para os interessados em se aprofundar nessa poderosa plataforma:

51nY36Dqo5L._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA300_SH20_OU01_

Spring in Action  é o livro mais básico que te ensina os pilares do uso de serviços no Spring. Nele você também aprendera os serviços e recursos mais básicos que ele proporciona.

415x7PWAe5L._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA300_SH20_OU01_

Just Spring Integration  é o livro que estende o spring oferecendo os serviços de infraestrutura voltados para integração de soluções definidos pelo catalogo de patterns de integração conhecidos pelo EAI.

51RXnaly93L

Spring Data é o livro que estende o spring oferecendo os serviços de infraestrutura voltados para persistência de dados relacionados com banco de dados relacionais e NoSQL.

Existem outros livros mais específicos de outros serviços que você também pode estar estudando como, por exemplo, Spring Bath in Action e Pro Spring Security

Uma vez que você domine todos estes serviços, você praticamente se tornara um “Arquiteto Java Spring”, dominando contextos de soluções mais modernos da atualidade e apto para projetar soluções corporativas de pequeno, médio e grande porte.

“Filhinhos meus, estas coisas vos escrevo para que não pequeis. Se, todavia, alguém pecar, temos Advogado junto ao Pai, Jesus Cristo, o Justo;” 1 João 2:1

Como se transformar em um arquiteto de software?

images

Estes dias atras me perguntaram quais seriam as informações mais básicas para se tornar um arquiteto de software. Segue ai a resposta bem resumida:

1)Modelo C4

Para o plano arquitetural conhecido como “blueprint” de um projeto, se faz necessário projetar a solução usando diagramas. Esqueça a UML! Eu uso modelo chamado de “C4”. Aprenda nesse livro: https://leanpub.com/software-architecture-for-developers .

2)Projeto e Design DDD

Para o design de camadas e projeto oop, se faz necessário uma abordagem 100% OO. Eu uso uma técnica chamada a de “Domain Driven Design”. Aprenda nesse livro: http://www.altabooks.com.br/domain-drive-design-atacando-as-complexidades-no-coracao-do-software.html .

3)Desenvolvimento TDD

Para o desenvolvimento, se faz necessário usar uma abordagem de construção de software. Eu uso uma técnica chamada de “Test Driven Design”. Aprenda nesse livro: http://www.casadocodigo.com.br/products/livro-tdd .

4)Design Emergente

Para criação e evolução da estrutura do produto em desenvolvimento, se faz necessário o uso de alguma abordagem. Eu uso uma chama de”Design Emergent”. Aprenda  nesse livro: http://www.amazon.com/Emergent-Design-Evolutionary-Professional-Development/dp/0321889061

Agora é com você :) ! Bons estudos a todos…

Se você precisar de uma ajuda extra e tem interesse em investir em cursos, nossa grade de arquitetura cobre a maioria desses tópicos, veja:  https://fernandofranzini.wordpress.com/2015/01/12/treinamentos-arquitetura-de-software-2015/

“Ora, nós conhecemos aquele que disse: A mim pertence a vingança; eu retribuirei. E outra vez: O Senhor julgará o seu povo. Horrível coisa é cair nas mãos do Deus vivo.” Hebreus 10:30-31

Os 10 enganos mais comuns no DDD que se deve evitar

670px-Avoid-Plagiarism-Step-7Não interagir com especialistas do domínio é um dos enganos cometidos quando se utiliza Domain-Driven Design (DDD). Identificá-lo e corrigi-lo o mais breve possível pode evitar retrabalho da equipe e consequentemente, não gerar impacto negativo no cronograma do projeto, afirma Daniel Whittaker, quando descreve sobre os dez erros que regularmente os desenvolvedores cometem.

Não interagir com especialistas do domínio é um dos enganos cometidos quando se utilizaDomain-Driven Design (DDD). Identificá-lo e corrigi-lo o mais breve possível pode evitar retrabalho da equipe e consequentemente, não gerar impacto negativo no cronograma do projeto, afirma Daniel Whittaker, quando descreve sobre os dez erros que regularmente os desenvolvedores cometem.

Permitir que a persistência ou repositório de dados influencie no modelo.

Tacticz/as/a/al patterns – Considerar as bases do negócio, simplificar modelos e isolá-los das preocupações com infraestrutura, como por exemplo: o repositório de dados. Iniciar com a modelagem de dados ao invés de, primeiramente, falar com especialistas do domínio pode criar um código baseado no modelo relacional ao invés de construir um modelo do domínio, o qual realmente refletirá as características do negócio. Ainda neste assunto, Stefan Tilkov alertou sobre o uso de um modelo dados canônico dentro de uma empresa, aonde os atributos opcionais e comportamentos atípicos poderiam trazer problemas na composição do modelo.

Não se envolver com os especialistas do domínio.

Falar com especialistas do negócio para obter a compreensão do domínio do problema a partir de suas perspectivas faz parte do núcleo do DDD. O Behaviour-Driven Development (BDD) enfatiza a realização de conversas com os especialistas do domínio, criando exemplos de comportamento. Além disso, Konstantin Kudryashov falou sobre a utilização das práticas do BDD e DDD em conjunto.

Ignorar a linguagem dos especialistas do domínio.

Criar uma linguagem ubíqua compartilhada com os especialistas do domínio é também uma prática presente no núcleo do DDD. Esta linguagem de comum entendimento deve ser utilizada em todas as discussões e além disso, aplicada diretamente no código, por meio de nomes de classes e métodos.

Não identificar a fronteira e a limitação dos contextos.

Uma abordagem comum para resolver problemas complexos é dividi-los em partes menores. Sendo assim, ao estabelecer a limitação dos contextos (Bounded Contexts) é possível trabalhar uma parte coesa e de menor complexidade em relação ao domínio completo ao invés de trabalhar com o todo. Esta estratégia também é conceito chave em microservices, conforme mencionado por Eric Evans em seu keynote neste ano, na conferência: DDD Exchange.

Usar um modelo de domínio anêmico.

Este é um sinal comum de que a equipe não está fazendo DDD e muitas vezes um sintoma de uma falha no processo de modelagem. A princípio um modelo de domínio anêmico muitas vezes parece um modelo de domínio real, com nomes corretos etc. Contudo, nota-se que nas classes está faltando boa parte do comportamento necessário, ao invés de apresentar as devidas operações, somente existem classes contendo métodos getters e setters para as propriedades.

Os cinco erros restantes que Whittaker identificou são:

Manter a limitação dos contextos (Bounded Contexts) apesar de obter-se um melhor entendimento a respeito do domínio. Uma vez que o processo de descoberta do domínio evolui constantemente, torna-se necessário garantir que os demais artefatos do projeto serão compatibilizados com ele.

  • Assumir que toda lógica é a lógica do domínio;
  • Fazer uso excessivo de testes de integração;
  • Tratar aspectos de segurança como parte do domínio (a menos que se esteja trabalhando em um domínio de segurança);
  • Concentrar-se na infraestrutura.

O último engano mencionado por Whittaker é não estar atento ao Event Storming, um processo de design com foco em eventos criado por Alberto Brandolini. Ao reunir os principais envolvidos em uma sala com espaço de modelagem abrangente e utilizar adesivos para representar os eventos do domínio, Brandolini afirma que eles podem em horas, produzir um modelo muito bom sobre o domínio do problema.

Fonte: http://www.infoq.com/br/news/2015/09/ddd-mistakes?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global

Tem interesse em aprender DDD ? Veja nosso treinamento em arquitetura AQT M3 – Arquiteto Java – Projeto e Design.

“É mais fácil um camelo passar pelo fundo de uma agulha, do que entrar um rico no reino de Deus”. Marcos 10:25

As distorções no papel de arquiteto de software

como-identificar-um-profissional-de-talento_Quando entrevisto candidatos à vagas de arquiteto de software, faço perguntas como: “Você acha que um arquiteto deveria programar?” Usualmente recebo uma destas duas respostas:

  • “Não, busco uma posição na qual eu não precise mais programar.”
  • “Eu adoraria continuar programando pelo menos um pouco mas, provavelmente, não terei tempo.”
  • “Já faz um tempo.”

Estas respostas são preocupantes. Desde quando evoluir profissionalmente em uma função da área técnica significa separar definições tecnológicas das atividades de desenvolvimento? Como alguém espera conseguir acompanhar o vasto cenário de opções em termos de tecnologia e compreender seu papel dentro das organizações, sem estar constantemente em contato com o time responsável pelo desenvolvimento destas tecnologias? Ou, ainda melhor, desenvolvendo ativamente as mesmas?

Veja o artigo completo no site infoq = http://www.infoq.com/br/articles/architects-should-code-bryson?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global

Para os interessados no assunto, veja a nossa grade de treinamentos para novos aspirantes em arquitetos de software: https://fernandofranzini.wordpress.com/2015/01/12/treinamentos-arquitetura-de-software-2015/

“Dessarte, não pode haver judeu nem grego; nem escravo nem liberto; nem homem nem mulher; porque todos vós sois um em Cristo Jesus.” Gálatas 3:28

Operações com Retry em Java

retryNa engenharia de software ágil que eu prático, existe uma regra simples que me salva de muitas dores de cabeça: “O menos é mais!”Isso quer dizer que como regra, eu sempre tento ao máximo fazer ou criar uma solução mais simples possível. Nesse contexto, algumas soluções Java precisam de operações de “retry” automáticos. Antes de você concluir que precisa de um servidor de mensageria com persistência de fila, considerar outras opções mais simples é de grande valor e pode te surpreender. Segue algumas estratégias de retry simples com Java:

“Respondeu-lhes Jesus: A obra de Deus é esta: que creiais naquele que por ele foi enviado.” João 6:29

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 611 outros seguidores