Categoria: Gestão

Conceito, Contexto e Partido na Computação

Publicado em por @anselme
Conclusão de Conceito, Contexto e Partido na Computação

A tríade “Conceito, Contexto e Partido” vem da arquitetura civil, onde foi usada para garantir que os projetos de construção fossem esteticamente agradáveis, funcionais e bem integrados ao seu ambiente. Adaptada para a arquitetura de software, essa abordagem ajuda a garantir que os sistemas e aplicações não só cumpram seus objetivos principais, mas também se encaixem bem nas condições em que serão utilizados e sejam desenvolvidos com uma estratégia eficaz. Assim, mesmo que o software seja baseado em bits e bytes, a tríade contribui para criar soluções práticas, adaptáveis e eficientes.

Procrastinação na TI e a Lei de Parkinson

Publicado em por @anselme
A Lei de Parkinson nos mostra que o tempo disponível para concluir uma tarefa pode influenciar diretamente a eficiência e a produtividade, especialmente devido à procrastinação. Na gestão de projetos de TI, compreender e combater essa tendência é essencial para garantir o sucesso. Implementar prazos mais curtos e realistas, dividir tarefas em blocos menores, priorizar e planejar adequadamente, além de adotar metodologias ágeis, são estratégias eficazes para minimizar os efeitos da procrastinação e da Lei de Parkinson.

A Lei de Parkinson nos mostra que o tempo disponível para concluir uma tarefa pode influenciar diretamente a eficiência e a produtividade, especialmente devido à procrastinação. Na gestão de projetos de TI, compreender e combater essa tendência é essencial para garantir o sucesso. Implementar prazos mais curtos e realistas, dividir tarefas em blocos menores, priorizar e planejar adequadamente, além de adotar metodologias ágeis, são estratégias eficazes para minimizar os efeitos da procrastinação e da Lei de Parkinson.

Estrutura em Larga Escala com DDD

Publicado em por @anselme
as estruturas propostas por Eric Evans oferecem um guia para arquitetos e desenvolvedores, permitindo a criação de sistemas flexíveis e adaptáveis. Assim, é bom compreender que não há uma abordagem única ou definitiva para projetar sistemas em larga escala. Desse modo, a flexibilidade e a capacidade de adaptação ao longo do tempo são essenciais: As estruturas apresentadas, como metáforas, camadas de responsabilidade, ordem de evolução, nível de conhecimento e estrutura de componentes plugáveis, fornecem um ponto de partida sólido.

As estruturas propostas por Eric Evans oferecem um guia para arquitetos e desenvolvedores, permitindo a criação de sistemas flexíveis e adaptáveis.Assim, é bom compreender que não há uma abordagem única ou definitiva para projetar sistemas em larga escala. Desse modo, a flexibilidade e a capacidade de adaptação ao longo do tempo são essenciais: As estruturas apresentadas, como metáforas, camadas de responsabilidade, ordem de evolução, nível de conhecimento e estrutura de componentes plugáveis, fornecem um ponto de partida sólido.

Domínio destilado

Publicado em por @anselme
O artigo Domínio Destilado apresenta uma interpretação prática e simplificada do Domain-Driven Design (DDD), abordando tópicos como: o que é domínio, declaração de visão do domínio, sub-domínios genéricos, mecanismos coesos etc. Ele destaca a importância de entender profundamente o domínio de negócio e de aplicar esses conceitos de forma prática no desenvolvimento de software, visando criar sistemas mais alinhados com as necessidades reais da organização.

O Domínio Destilado apresenta uma interpretação prática e simplificada do Domain-Driven Design (DDD), abordando tópicos como: o que é domínio, declaração de visão do domínio, sub-domínios genéricos, mecanismos coesos etc. Ele destaca a importância de entender profundamente o domínio de negócio e de aplicar esses conceitos de forma prática no desenvolvimento de software, visando criar sistemas mais alinhados com as necessidades reais da organização.

Bounded Contexts livres

Publicado em por @anselme
Os Bounded Contexts Livres representam uma abordagem interessante no desenvolvimento de software, permitindo uma visão mais flexível e modular do sistema. No entanto, é essencial ter em mente os desafios associados, especialmente em relação à manutenção da clareza e organização do código, para evitar que esses contextos se tornem "Big Balls of Mud". Portanto, adotar práticas e padrões de design adequados, como os propostos pelo DDD, pode ser fundamental para controlar a complexidade e garantir a sustentabilidade dos sistemas de software ao longo do tempo.

Os Bounded Contexts Livres representam uma abordagem interessante no desenvolvimento de software, permitindo uma visão mais flexível e modular do sistema. No entanto, é essencial ter em mente os desafios associados, especialmente em relação à manutenção da clareza e organização do código, para evitar que esses contextos se tornem “Big Balls of Mud”. Portanto, adotar práticas e padrões de design adequados, como os propostos pelo DDD, pode ser fundamental para controlar a complexidade e garantir a sustentabilidade dos sistemas de software ao longo do tempo.

O Desenvolvedor acabou! Será?

Publicado em por @anselme
O DEVIN representa um avanço significativo na automação do desenvolvimento de software, oferecendo uma nova abordagem para a criação de sistemas e levantando questões importantes sobre o futuro da profissão de desenvolvedor. Embora o DEVIN possa aumentar a eficiência e a produtividade no desenvolvimento de software, é importante considerar os desafios e responsabilidades éticas que surgem com o uso dessa tecnologia, além de como os profissionais podem se adaptar a essa nova realidade e continuar a agregar valor no mercado de trabalho. O Desenvolvedor acabou! Será?

O DEVIN representa um avanço significativo na automação do desenvolvimento de software, oferecendo uma nova abordagem para a criação de sistemas e levantando questões importantes sobre o futuro da profissão de desenvolvedor. Embora o DEVIN possa aumentar a eficiência e a produtividade no desenvolvimento de software, é importante considerar os desafios e responsabilidades éticas que surgem com o uso dessa tecnologia, além de como os profissionais podem se adaptar a essa nova realidade e continuar a agregar valor no mercado de trabalho. O Desenvolvedor acabou! Será?

Bounded Contexts: Upstream-Downstream

Publicado em por @anselme
Compreender eficazmente as relações Upstream-Downstream é essencial para o sucesso de um sistema baseado em Domain Driven Design com Bounded Contexts. Então, ao identificar claramente essas relações e aplicar estratégias adequadas, como a utilização de Open-host Services, Published Languages, e Anticorruption Layers, é possível minimizar conflitos e garantir a integridade e a evolução dos diferentes contextos de forma independente. Portanto, ao projetar arquiteturas de software baseadas em DDD, é fundamental considerar não apenas os limites dos contextos, mas também as interações entre eles, visando uma arquitetura flexível, escalável e resiliente.

Compreender eficazmente as relações Upstream-Downstream é essencial para o sucesso de um sistema baseado em Domain Driven Design com Bounded Contexts. Então, ao identificar claramente essas relações e aplicar estratégias adequadas, como a utilização de Open-host Services, Published Languages, e Anticorruption Layers, é possível minimizar conflitos e garantir a integridade e a evolução dos diferentes contextos de forma independente. Portanto, ao projetar arquiteturas de software baseadas em DDD, é fundamental considerar não apenas os limites dos contextos, mas também as interações entre eles, visando uma arquitetura flexível, escalável e resiliente.

Bounded Contexts de dependência mútua

Publicado em por @anselme
os Bounded Contexts de dependência mútua representam um desafio significativo na arquitetura de sistemas baseados em DDD. A necessidade de compartilhar lógica, dados e estruturas entre contextos distintos exige um cuidado especial na definição e na implementação desses padrões de relacionamento. É essencial que os arquitetos e desenvolvedores compreendam bem os princípios do DDD e busquem sempre a clareza e a coesão em seus designs para evitar armadilhas comuns que levem a inconsistência de dados, conceitos ou intenções.

Os Bounded Contexts de dependência mútua representam um desafio significativo na arquitetura de sistemas baseados em DDD. A necessidade de compartilhar lógica, dados e estruturas entre contextos distintos exige um cuidado especial na definição e na implementação desses padrões de relacionamento. É essencial que os arquitetos e desenvolvedores compreendam bem os princípios do DDD e busquem sempre a clareza e a coesão em seus designs para evitar armadilhas comuns que levem a inconsistência de dados, conceitos ou intenções.

Interfaces reveladoras de intenções

Publicado em por @anselme
a essência de construir software significativo: a clareza nas intenções. A fundamentação de Interfaces Reveladoras de Intenções revela-se não apenas como uma prática técnica, mas como um compromisso fundamental com a comunicação eficaz entre o domínio e o código. A clareza nas intenções, desde os nomes das classes até a construção de interfaces, não é uma mera formalidade, mas uma estratatégia consistente para redução da sobrecarga cognitiva, garantindo a longedidade do sistema. Ao abraçar abstrações claras, explicitar conceitos implícitos e adotar práticas como TDD e BDD, fortalecemos não apenas a robustez do código, mas também a capacidade de evolução do software.

A essência de construir software significativo: a clareza nas intenções. A fundamentação de Interfaces Reveladoras de Intenções revela-se não apenas como uma prática técnica, mas como um compromisso fundamental com a comunicação eficaz entre o domínio e o código. A clareza nas intenções, desde os nomes das classes até a construção de interfaces, não é uma mera formalidade, mas uma estratatégia consistente para redução da sobrecarga cognitiva, garantindo a longedidade do sistema. Ao abraçar abstrações claras, explicitar conceitos implícitos e adotar práticas como TDD e BDD, fortalecemos não apenas a robustez do código, mas também a capacidade de evolução do software.

Desenvolver na empresa ou comprar pronto?

Publicado em por @anselme
Ao ponderar sobre "fazer ou comprar", as empresas devem ir além dos custos diretos e considerar a implicação estratégica a longo prazo. A decisão não é uma escolha única, mas sim uma série de decisões ao longo do tempo, moldadas pela visão da empresa e sua busca constante pela inovação. Então, de modo geral, com adequadas ponderações, iniciativas de transformação (transformation) sempre devem ser feitos em casa; iniciativas de crescimento (grow) podem ser produtos prontos; iniciativas de continuidade da operação (run) devem ser produtos de prateleira.

Em um mundo onde a inovação se tornou a palavra de ordem, a decisão estratégica entre desenvolver internamente e adquirir soluções prontas é um desafio de todas as organizações. Então, a diversidade de demandas, desde iniciativas estratégicas até serviços contínuos, destaca a necessidade de uma abordagem flexível e contextualizada. Assim, o modelo Run-Grow-Transform oferece uma estrutura útil para classificar essas demandas, permitindo que as empresas direcionem seus esforços de maneira mais eficaz.