Esse é um Readme que decidi fazer para estudos, para conseguir massificar as informações que tenho estudado ultimamente e lapidar alguns conceitos que já conhecia.
Meu objetivo é ter tudo na ponta da lingua e saber explicar sem travar em nenhum momento, sobre todos os tópicos abordados.
Com o tempo eu vou adicionando mais tópicos conforme vou estudando sobre mais assuntos que ao meu ver parecem interessantes.
Todos os tópicos serão atualizados frequentemente conforme vou estudando mais sobre eles.
Tudo escrito na unha. 😀
- Algoritmos de busca e de ordenação
- Apache Kafka
- Arquitetura Hexagonal
- Banco de imagens
- BDD
- Clean Architecture
- DDD
- Design Patterns
- Diferença entre interface e classe abstrata no Java
- Ferramentas de pagamento
- NoSQL
- O que é a memória HEAP?
- Padrões de projeto
- Paleta de cores
- Pipeline
- REST x SOAP
- SOLID
- Scrum
- Serializable
- Spring Security
- STRATEGY: Sequence vs Identity
- TDD
- Tipos de atribuições de valores
- Triggers e procedures?
- VO x DTO x DAO x BO x Bean
- WebFlux
- XPages
Source
1 - Mensageria:
O Kafka funciona bem como substituto para brokers de mensagens tradicionais. Os brokers de mensagens são usados por diversas razões (para separar o processamento dos produtores de dados, para armazenar mensagens não processadas, etc).
Em comparação com a maioria dos sistemas de mensagens, o Kafka possui a melhor taxa de transferência, particionamento incorporado, replicação e tolerância a falhas, o que torna uma boa solução para aplicativos de processamento de mensagens de larga escala.
Esse uso é comparável a sistemas de mensagens tradicionais, como ActiveMQ ou RabbitMQ.
2 - Rastreamento de atividades de sites:
O caso de uso original do Kafka era reconstruir um pipeline de rastreamento de atividades do usuário como um conjunto de feeds de publicação e assinatura em tempo real. Isso significa que as atividades do site (visualizações de página, pesquisas ou ações que os usuários possam fazer) são publicadas em tópicos centrais, com um tópico por tipo de atividade. Esses feeds estão disponíveis para assinatura em uma variedade de casos de uso, incluindo processamento em tempo real, monitoramento em tempo real e carregamento em sistemas Hadoop ou data warehouses offline para processamento em relatórios offline.
O rastreamento de atividades geralmente gera um grande volume de mensagens, pois muitas mensagens de atividades são geradas para cada visualização de página do usuário.
3 - Métricas:
O Kafka é frequentemente usado para dados de monitoramento operacional. Isso envolve a agregação de estatísticas de aplicativos distribuídos para produzir feeds centralizados de dados operacionais.
4 - Agregação de logs:
Muitas pessoas usam o Kafka como substituto para uma solução de agregação de logs. A agregação de logs geralmente coleta arquivos de log físicos de servidores e os coloca em um local centralizado (um servidor de arquivos ou HDFS, por exemplo) para processamento.
O Kafka abstrai os detalhes dos arquivos e fornece uma abstração mais limpa dos dados de log ou evento como um fluxo de mensagens. Isso permite processamento com latência reduzida e suporte mais fácil para várias fontes de dados e consumo de dados distribuído.
Em comparação com sistemas centrados em logs como Scribe ou Flume, o Kafka oferece desempenho igualmente bom, garantias de durabilidade mais fortes devido à replicação e latência de ponta a ponta muito menor.
5 - Processamento de fluxo:
Muitos usuários do Kafka processam dados em pipelines de processamento compostos por vários estágios, nos quais os dados brutos de entrada são consumidos a partir de tópicos do Kafka e, em seguida, agregados, enriquecidos ou transformados de outras formas em novos tópicos para consumo ou processamento subsequente. Por exemplo,
um pipeline de processamento para recomendar artigos de notícias pode coletar o conteúdo do artigo de feeds RSS e publicá-lo em um tópico "artigos";
um processamento posterior pode normalizar ou deduplicar esse conteúdo e publicar o conteúdo do artigo depurado em um novo tópico;
uma etapa final de processamento pode tentar recomendar esse conteúdo aos usuári9os.
Esses pipeline de processamento criam gráficos de fluxos de dados em tempo real com base nos tópicos individuais. A partir da versão 0.10.0.0, uma biblioteca de processamento de fluxo leve, porém poderosa, chamdaa Kafka Streams, está disponível no Apache Kafka para realizar esse processamento de fluxo de código aberto alternativas incluem o Apache storm e o Apache Samza.
6 - Event Sourcing:
Event sourcing é um estilo de design de aplicativo no qual as alterações de estado são registradas como uma sequência de registros ordenados por tempo. O suporte do Kafka para armazenamento de log muito grande o torna um excelente backend para um aplicativo construído nesse estilo.
7 - Commit Log:
O Kafka pode servir como um tipo de log de confirmação externo para um sistema distribuído. O log ajuda a replicar dados entre nós e atua como um mecanismo de ressincronização para nós com falha restaurarem seus dados. O recurso de compactação de log no Kafka ajuda a suportar esse uso. Nesse caso, o Kafka é semelhante ao projeto Apache BookKeeper.
"Se os programadores não estão interessados no domínio, eles aprendem apenas o que a aplicação deve fazer, não os princípios por trás dela."
- Eric Evans
O DDD, Domain-Driven Design ou simplesmente Design Orientado ao Domínio, é uma abordagem para a modelagem de software que tem como foco principal a criação de um modelo de domínio.
Baseia-se na implementação de modelos que refletem as competências e a complexidade do negócio da organização.
Essa abordagem oferece ferramentas de modelagem estratégica e tática, com o objetivo de entregar um software de alta qualidade.
É especialmente útil no desenvolvimento de aplicações que lidam com processos de negócios complexos, proporcionando uma aceleração no seu desenvolvimento.
Pode ser utilizado independente da linguagem.
Não é: forma de organizar pastas, organização de código, tecnologia, framework, arquitetura ou metodologia. Também não impõe processos rígidos ao time.
Alguns dos termos utilizados são: Design estratégico e design tático.
Começando pelo design tático ou modelagem tática, é basicamente a implementação utilizando o Domain Model Pattern
(uma abordagem que diz como escrever as classes que irão mapear os modelos do mundo real e implementar os comportamentos do negócio).
Padrões no design tático: Entities e Value Objects definem os conceitos do domínio. Domain Service assume a responsabilidade que não se encaixa em outros projetos. Aggregates que define fronteiras entre objetos. Factory e repositories que lida com a criação e armazenamento de objetos.
O design estratégico ou modelagem estratégica, é a parte teórica. As informações abaixo fazem parte do padrão estratégico.
"O Design Estratégico é como fazer o rascunho antes de entrar nos detalhes da implementação. Que ele destaca o que é estrategicamente importante para o negócio; como dividir o trabalho por importância; e como fazer integrações da melhor maneira"
- Vaughn Vernon
Diferente da hospedagem de sites, o domínio abordado nesse tópico é o negócio da sua empresa ou o assunto do seu projeto. Então, precisa necessariamente entender o negócio para ser possível
de implementar o DDD em um projeto. Nessa implementação existem 2 papeis: o time de desenvolvimento e os domain experts
Existem alguns pilares no DDD:
- Linguagem Ubíqua: utilizada por toda a equipe do projeto. Criada justamente para facilitar a comunicação e o entendimento dos termos específicos utilizados tantos pelo time de desenvolvimento quanto pelo domain experts, onde cada entidade possui termos onde são necessários "uma tradução" para haver uma comunicação clara entre ambos os times.
- Bounded Context: delimitação do contexto. Uma vez que todo domínio é colocado em um modelo, para evitar que seja complexo demais, delimitará esses contextos baseados nas intenções de negócio.
Cada bounded context pode ter sua linguagem ubíqua, sua abordagem de arquitetura, de armazenamento de dados e até a própria equipe de desenvolvimento.
Para criar esse modelo e entender como os bounded contexts se relacionam e como se comunicam é utilizado o Context map(um modelo que dará uma visão geral do software,
geralmente um desenho simples que da para ser feito com uma caneta e um quadro branco).
Existem alguns padrões de relacionamento entre os bounded contexts e implicam diretamente na estratégia de como os times de projeto irão trabalhar. Na dependência entre eles, na arquitetura e até na
estratégia de comunicação. Os principais tipos de relacionamentos entre os contextos são:
Shared Kernel: Quando vários bounded contexts, compartilham do mesmo domínio. Alterando-o, afetará todas as equipes.
Customer-Supplier Development: quando existe um relacionamento de cliente-fornecedor, ou, Downstream e Upstream. A Equipe Upstream pode ter êxito interdependente da equipe Downstream. Um contexto é o fornecedor do serviço e o outro é o consumidor. As equipes definirão testes de aceitação automatizados que irão validar as interfaces que a equipe de Upstream fornece, com isso as equipes de fornecedores poderá fazer as modificações sem se preocupar em quebrar o sistema. Tipos de relacionamentos Customer-Supplier Development:
- Conformist: relacionamento onde o bounded context downstream se conforma que o modelo upstream não atende suas necessidades e as modificações realizadas por ele impactam diretamente em seu contexto. Mas ele se vira.
- Partner: nesse relacionamento os bounded contexts parceiros, unidos por uma dependência mutua e deverão trabalhar em conjunto.
- Anticorruption Layer: ja nesse relacionamento a equipe downstream cria uma camada para proteger o seu contexto das modificações do upstream (comum em sistemas legados).
Utilizar quando precisar de uma lista redimensionável, onde você adiciona e remove elementos com frequência e não precisa de acesso rápido aleatório aos elementos.
Utilizar quando precisar de uma lista onde você adiciona e remove elementos frequentemente do início ou do final da lista ou quando precisa de acesso rápido a elementos próximos.
Utilizar quando precisar de uma coleção que não permite duplicatas e a ordem dos elementos não é importante.
Utilizar quando precisar de uma coleção que não permite duplicatas e os elementos devem estar em ordem natural ou definida por um comparador.
Utilizar quando precisar de uma coleção que não permite duplicatas e você deseja manter a ordem de inserção dos elementos.
Utilizar quando precisar associar chaves a valores e a ordem das chaves não é importante. É uma boa escolha para buscar rapidamente por chaves.
Utilizar quando precisar associar chaves a valores e as chaves devem estar em ordem natural ou definida por um comparador.
Utilizar quando precisar associar chaves a valores e desejar manter a ordem de inserção das chaves
List:
Set: Interface. Não permite duplicatas. Map: Interface. Associa chaves a valores. HashSet: Classe. HashMap: Classe.
'Tree': Elementos em ordem natural ou definida por um comparador. 'Hash': Ordem dos elementos não é importante. 'LinkedHash': Mantem a ordem de inserção das chaves.
Colunas / Chave-valor / Grafos / Documentos
Lista de banco de dados NoSQL
Interfaces:
- Só pode ter métodos abstratos.
- Definem apenas a assinatura dos métodos que as classes devem implementar.
- Uma classe pode implementar várias interfaces, herdando o comportamento.
- Não pode ter construtores.
- É um contrato que define os métodos que uma classe deve implementar, não pode ser instanciada.
- Necessária quando é pra definir um contrato comum a um grupo de classes não necessariamente relacionadas, permitindo que compartilhem de comportamentos independentemente de sua hierarquia.
Classes Abstratas:
- Pode ter métodos abstratos(sem implementação) e métodos concretos.
- Pode ser estendida por uma ou várias classes.
- Pode ter construtores.
- Pode ser instanciada.
- Necessária quando é pra fornecer uam implementação padrão para um conjunto de classes relacionadas e que também deseja permitir que essas classes personalizem partes específicas do comportamento.
Anotações: Spring Security gera o usuário user com senha aleatória sempre que é executado, caso não seja configurado no application.properties o usuário e a senha. Também é criado na url localhost:8080/login o formulário de login padrão do spring security
Ferramentas para trabalhar com integração de pagamento:
Internacional: Stripe
Nacional: PagSeguro / Pagar.me
- Atribuição por valor - Quando o valor real da variável é copiado e atribuído a outra variável ou passado como argumento para uma função. Variáveis com cópia independente de seus valores.
- Atribuição por referência - Quando um ponteiro ou referência para a memória em que o valor está armazenado é copiado. Duas variáveis referenciando um mesmo objeto na memória e, portanto, qualquer alteração em uma variável afetará a outra.
Agora em relação ao Java...
Memória HEAP é uma memória usada para armazenar objetos e instâncias de classes, com alocação e desalocação controladas pelo programador.
Por outro lado, temos a memória stack que é usada para armazenar variáveis locais e dados relacionados às chamadas de função, com alocação e
desalocação automáticas.
No Java, a memória heap é usada para alocar objetos e é gerenciada automaticamente pelo garbage collector.
Já a memória stack é usada para armazenar variáveis locais e referências a objetos.
"Cada padrão descreve um problema que ocorre frequentemente em seu ambiente, e então descreve o cerne da solução para aquele problema, de um modo tal que você pode usar esta solução milhões de vezes, sem nunca fazer a mesma coisa repetida."
- Christopher Alexander
Estou estudando 3 tipos de padrões de projeto: Criacionais, Estruturais e Comportamentais.
Primeiramente vou começar com um breve resumo sobre cada um.
Padrões de projetos Criacionais basicamente existem diversos mecanismos para criar um objeto. Ao invés de utilizar diretamente o operador "new", podemos utilizar algum padrão que nos forneça mais flexibilidade no código.
Padrões de projetos Estruturais mostra como objetos podem se unir em estruturas maiores, porém de forma organizada, facilitando possíveis extensões.
Padrões de projetos Comportamentais organiza a forma de comunicação entre os objetos.
Anotação para organização futura:
Padrões de projeto Criacionais: Factory Method, Abstract Factory, Singleton, Monostate, Builder, Prototype.
Padrões de projeto Estruturais: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy.
Padrões de projeto Comportamentais: Chain of Responsability, Memento, Command, Iterator, Mediator, Observer, State, Strategy, Template Method.
Clean Architecture, ou arquitetura limpa, é um conceito de design semelhante a arquitetura hexagonal (possui algumas diferenças).
O design dessa arquitetura é composto por várias camadas concêntricas, cada uma representando um nível de abstração e isolando diferentes tipos de responsabilidades.
Os níveis de abstrações dessa arquitetura visa a separação clara entre regras de negócio e detalhes de implementação técnica. É uma abordagem que busca manter o núcleo das regras de negócio independente de frameworks, banco de dados e outros detalhes externos, promovendo modularidade, testabilidade e evolução sustentável do software ao longo do tempo.
As camadas internas, como Entidades e Casos de Uso, concentram-se na lógica de negócios, enquanto as camadas externas, como Adaptadores de Interface e Frameworks, tratam dos aspectos técnicos e de interação com o ambiente.
É uma lista contendo tudo o que deseja que seja contemplado pelo projeto para chegar em um produto. Contém os requisitos do sistema.
História do Usuário/User story
É cada requisito registrado no Backlog do Produto.
É cada interação que ocorre com períodos fixos para ser trabalhado no desenvolvimento de um produto entregável. Geralmente tem duração de 2 a 4 semanas.
Durante a sprint é retalizado uma lista de requisitos(retirados do backlog do produto) a serem trabalhados que foram previamente acordados e essa lista é chamada de Sprint Backlog
que é definida no início de cada sprint durante o evento que é chamado de Spring Planning(planejamento da sprint).
Ao longo da sprint é comum que a equipe realize reuniões dirárias que são chamadas de Daily Scrum ou Daily Stand-up onde é discutido o processo, o que foi concluído desde a última reunião e quaisquer impedimentos que estejam afetando o trabalho.
Ao final da Sprint ocorre o processo que é chamado de Sprint Review onde é feita a demonstração do incremento do produto à equipe de Stakeholders e recebe feedback.
Após a Sprint Review, ocorre o Sprint Retrospective uma reunião em que a equipe reflete sobre o processo de trabalho da sprint anterior e indetifica oportunidades de melhoria para a próxima sprint.
O implements Serializable é necessário pois existem frameworks de banco de dados que não realizam a serialização automática do objeto, tornando-se necessário utilizar o implements serializable.
Serialização nada mais é que a transformação de um objeto em uma cadeia de bytes para ser manipulado mais facilmente, seja através de transporte pela rede ou salvo pelo disco.
2. O -> Open-Closed Principle (Princípio Aberto-Fechado)
3. L -> Liskov Subtitution Principle (Princípio da substituição de Liskov)
4. I -> Interface Segregation Principle (Princípio da Segregação da Interface)
5. D -> Dependency Inversion Principle (Princípio da inversão de dependência)
1. S - Princípio da Responsabilidade Única:
Este princípio afirma que uma classe deve ter apenas uma única responsabilidade ou motivo para mudar. Em outras palavras, uma classe deve ter apenas uma tarefa ou função bem definida. Isso torna a classe mais coesa e facilita a manutenção e evolução do código.
2. O - Princípio Aberto-Fechado:
Este princípio defende que uma classe deve estar aberta para extensão mas fechada para modificação. Isso significa que você pode estender o comportamento da classe adicionando novas funcionalidades sem modificar o código existente. Isso promove um código mais flexível e reutilizável.
3. L - Princípio da Substituição de Liskov:
Este princípio afirma que objetos de uma classe derivada devem poder ser substituídos pelos objetos da classe base sem alterar a corretude do programa. Isso Significa que uma subclasse deve ser substituível por sua classe base sem afetar o comportamento esperado do programa.
4. I - Princípio da Segregação da Interface:
Este princípio prega que uma classe não deve ser forçada a implementar interfaces que não utiliza. Em vez disso, é melhor ter interfaces menores e mais específicas, para que as classes possam implementar apenas o que é relevante para elas.
5. D - Princípio da Inversão de Dependência:
Este princípio sugere que as classes de alto nível não devem depender de classes de baixo nível diretamente, mas sim depender de abstrações. Além disso, as abstrações não devem depender de detalhes mas os detalhes devem depender das abstrações. Isso promove um desacoplamento entre as classes e facilita a manutenção e a extensão do sistema.
É uma prática iterativa em que primeiro são feitos os testes unitários para depois realizar a implementação no código de produção refatorando até todas as funcionalidades sejam corretamente implementadas.
DTO - Data Transfer Object
Exemplo de DTO:
User - id, login, senha (model)
UserDTO - id, login
Postman HTTP GET -> retorna objeto sem a senha do usuário.
DAO - Data Access Object
Dados relacionados aos SQL, DAO é mais próximo do banco de dados.
Geralmente para cada classe de modelo, criar uma classe 'modeloDAO'.
O DAO é a união de uma entidade com um conector. É uma classe capaz de encapsular as propriedades de uma entidade da mesma forma que possui métodos para persistir ou capturar aquelas informações do banco.
BO - Business Object
Pode ter tanto a camada de entidade quanto a de persistência na mesma classe, e sim, fere o SOLID.
Bean -
Primeira camada que se comunica com a interface da aplicação.
VO -
É um DTO só com atributos fixos. Strings ou Enums.
Não sei se pode forçar e jogar um 'int id';
Utilizado exclusivamente no Domino. Parece bastante o JSF.