Desenvolver na empresa ou comprar pronto?

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.

Entendendo o Apache Spark

O Apache Spark atualmente é a principal ferramenta na computação distribuída quando o assunto é bigdata. Diferentemente do passado hoje há um mercado muito vibrante com concorrentes, mas não tiram o brilho desse. Ele suporta linguagens de programação diferentes, algo fundamental para atrair programadores, engenheiros ou cientistas de dados. Suas estratégias internas são rebuscadas, como é o caso da LazyEvaluation e suas DAG's criadas sob medida. Além disso ele possui diversas bibliotecas públicas ao invés do tooling do Hadoop que tinha uma manutenção complicada. O artigo Entendendo o Apache Spark explora um pouco de tudo isso.

O Apache Spark atualmente é a principal ferramenta na computação distribuída quando o assunto é bigdata. Diferentemente do passado hoje há um mercado muito vibrante com concorrentes, mas não tiram o brilho desse. Ele suporta linguagens de programação diferentes, algo fundamental para atrair programadores, engenheiros ou cientistas de dados. Suas estratégias internas são rebuscadas, como é o caso da LazyEvaluation e suas DAG’s criadas sob medida. Além disso ele possui diversas bibliotecas públicas ao invés do tooling do Hadoop que tinha uma manutenção complicada. O artigo Entendendo o Apache Spark explora um pouco de tudo isso.

Domain Service no Domain Driven Design

Domain Service no Domain Driven Design: eles sempre são Stateless. Veja Exemplos relacionando agregados dicas sobre as boas práticas no uso.

O padrão tático Domain Service é amplamente utilizado no mercado mas é bem comum ver que ele não segue as recomendações do DDD de maneira não intencional. Assim, o artigo explica como o conceito Domain Service é aplicado no mercado e aplicado no DDD em si. Após isso o vemos em detalhes e por fim vemos uma pequena implementação real de seu uso.

Domain Driven Design tático

Os 7 padrões do DDD Tático

O DDD pode ser observado por dois grandes pontos de vista: o estratégico e o tático. O DDD estratégico oferece elementos conceituais robustos que ligam a estruturação do software com as características particulares do negócio. Já o Domain Driven Design tático dá meios para que implementações reais, independentes de linguagem de programação, consigam garantir a entrega das necessidades estratégicas. Muitos veem o DDD apenas do ponto de vista tático – com seu conjunto de Patterns – mas entenda que somente esse ponto sem a estratégia há um empobrecimento de seu uso e, de certo modo, destrói-se a implementação do DDD. Veja nesse artigo os 7 padrões do DDD tático e como eles podem ser utilizados.

Domain Driven Design estratégico

DDD - Domain Driven Design estratégico

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.