Desenvolvimento, Gestão, Arquitetura de Software, Estratégia, Cultura, Devops e afins
O post desvela não apenas uma metodologia técnica, mas uma visão filosófica sobre a construção de sistemas distribuídos. Os princípios fundamentais de transferência de estado, a linguagem universal do HTTP e a aplicação do conceito HATEOAS não apenas conectam sistemas, mas redefinem a própria essência da interconectividade digital. Além disso, o Modelo de Maturidade de Richardson oferece uma bússola, que embora questionável ela é didática, guiando as implementações.
Então, o HTTP é a base da World Wide Web. Assim, desde suas origens simples na HTTP 0.9 até a complexidade robusta da HTTP 3, essa evolução trouxe inovações substanciais que impactaram a forma como interagimos e nos conectamos online. Desse modo, à medida que avançamos, é fundamental acompanhar essa evolução para compreender as tendências atuais e futuras na navegação na web. O protocolo HTTP, em sua jornada de evolução, continua a moldar o futuro do ambiente digital, proporcionando uma experiência web mais rápida, segura e eficiente para todos os usuários.
O Hadoop materializou o conceito de bigdata e modificou toda a forma em que o mercado encara os dados. Ele tem uma arquitetura muito bem feita para suportar grandes volumes. Ele possui um sistema de arquivos distribuidos, o HDFS, que lida com esse problema. Além disso há o map-reduce que em alinhamento com o HDFS produz cálculos em massas inacreditáveis de dados: Ainda que utilizando vários computadores de desempenho mediano. Por fim o Yarn possibilizou uma maior extensibilidade do produto, dando abertura para novas ferramentas como o Zookeeper, Pig ou Spark. O Essencial do Hadoop dá uma visão panorâmica sobre o produto além de pequenos exemplos.
Ambas as arquiteturas são capazes de lidar com dados massivos, volumosos etc. com características particulares. O uso da Lambda é o mais popular, mas que exige mais tecnologias envolvidas, tem uma manutenção mais difícil; ao contrário da Kappa que simplifica tudo, porém pode não ter o histórico dos dados. Como de costume, trata-se de analisar um caso em específico para saber qual arquitetura se parece mais adequada.
Em resumo há muitos bancos de dados. Alguns deles existem há muito tempo mas se popularizaram a partir de 2010 para suportar o aumento crescente dos dados, das variedades dos dados e das arquiteturas emergentes. O Teorema CAP é uma estratégia para pensar em como selecionar bancos de dados para as arquitetura que se apresentam.
Nada impede de amanhã um novo tipo de banco de dados ganhar força, tendo em vista a variedade de dados que é crescente nos tempos atuais. Note que alguns desses bancos suportam múltiplos conceitos ao mesmo tempo. Mas ao final de tudo, analise com cuidado considerando as necessidades tecnológicas, as necessidades de negócio/custo, e as capacidades do time na hora de decidir por utilizar um tipo ou outro.
O domínio da aplicação deve ser sempre preservado, de modo que mudanças não o alterem e não impacte em testes. O artigo dá exemplos práticos de como pode-se utilizar esse padrão para leis, normas etc, especialmente aplicável em estruturas que precisam funcionar em conformidade. Definitivamente o padrão de especificações é muito flexível e uma boa prática.
A Factory do Domain Driven Design (DDD) é um padrão tático que pode ser utilizado de modos diferentes, com o objetivo de facilitar a geração de novos agregados. Lembre-se que a instância de objetos tem que ser fácil, mas isso nem sempre é aplicado desse modo nos códigos que vemos no dia-a-dia.
Modelando em 7 passos no VSCode: Veja um exemplo de uma corretora de criptomoedas do absoluto zero, passando por event storming, mapeando dos sub-domínios, relacionando contextos até chegar ao diagrama de contexto feito sob medida no Visual Studio Code.
Você também acha que usa DDD só porque tem pastinhas específicas organizando o código? Pensou errado!A estratégia da organização norteia tanto a estrutura corporativa (negócios existentes, modelos de negócio, fluxo de caixa, margens, etc.) quanto a própria estrutura do software, uma vez que ela tende a refletir tais características.Esse artigo vai da estratégia da organização até a estratégia associada ao DDD. Mas se seu objetivo é querer entender elementos como repository, agregações, value-objects ou mesmo estruturas de pastas comumente utilizadas em projetos desse tipo, entenda que esse artigo não entregará tais características. Pelo contrário, ele entregará os passos anteriores que fundamentam o uso do DDD numa empresa. Uma vez que entendo que esses elementos sem a estratégia não são DDD, mas tão somente nomes de pastas ou classes. De todo modo escreverei em algum momento um artigo sobre eles.