Início Domain Driven Design no InfoQ Brasil
Notícias
Feed RSS-
O método Swift: Uma estrutura para modernização de software usando DDD
O Método Swift é um conjunto de técnicas de análise de sistemas legados complexos a fim de determinar o trabalho necessário para modernizar gradualmente os principais componentes ou o sistema como um todo.
-
Sensatez e absurdos sobre Event Thinking e microservices
A modularidade dos sistemas que construímos é muito importante, mas para atingi-la devemos lidar com forças antimodularidade. Em uma apresentação na Conferência de Microservices Orientada a Eventos, realizada pela AxonIQ, Allard Buijze compartilhou os pensamentos e experiências na construção de sistemas baseados em DDD, CQRS, microservices e event sourcing.
-
Definindo Bounded Contexts — Eric Evans durante o DDD Europa
Um bounded context é uma parte definida do software em que termos e regras específicos se aplicam de maneira consistente, explicou Eric Evans em sua palestra durante a DDD Europa no início deste ano; deve possuir um modelo refinado e uma linguagem com definições não ambíguas. Ele descreve diferentes tipos de bounded contexts, incluindo alguns que envolvem microservices.
-
Código legível: Por que, como e quando você deve escrevê-lo
A maioria das pessoas diria que deseja código legível e pode até preferir a legibilidade à funcionalidade. Mas quando se trata de pedir às pessoas para definir a legibilidade, as opiniões divergem. No Explore DDD 2018, Laura Savino falou sobre porque queremos código legível, o que realmente significa ser legível e quando a legibilidade deve ter prioridade sobre outras considerações.
-
Encontrando contextos delimitados usando Narrativas de Domínio
As Narrativas de Domínio (Domain Storytelling) são uma forma de descobrir como as pessoas e sistemas trabalham juntos em um domínio, identificando os contextos delimitados e como estes se interconectam.
-
Vaughn Vernon utiliza DDD Reativo para modelar incertezas em microservices
Os microservices e sistemas reativos trouxeram incertezas sobre mensagens recebidas fora de ordem, recebidas múltiplas vezes ou, por fim, mensagem nenhuma. Como reagir a essas incertezas é uma decisão de negócios, diz Vaugh Vernon, e são melhor capturadas modelando as incertezas utilizando conceitos do Domain-Driven Design.
-
Capturar - Incorporar - Proteger: diretrizes para Domain-Drive Design
“Ao usar a filosofia e as práticas centrais do DDD como diretrizes para o design e desenvolvimento de software, podemos resumi-las em três princípios: Capturar - Incorporar - Proteger.”, afirmou Steven A. Lowe em sua apresentação na conferência DDD eXchange deste ano. Capture o domínio. Incorpore o modelo no código. Proteja o modelo de domínio da corrupção de outros domínios.
-
Os gerenciadores de processos em sistemas baseados em eventos
Publicar eventos para notificar sobre alterações num domínio mantém domínios diferentes desacoplados entre si, mas se realmente houver um fluxo lógico de eventos isso se torna implícito e difícil de acompanhar. Uma solução melhor é usar um gerenciador de processos (Process Manager) para acompanhar todo o processo, afirmou Bernd Rücker em sua apresentação deste ano na conferência DDD eXchange.
-
Escolhendo uma arquitetura orientada a eventos
Quando fazemos o design de um sistema distribuído, eventualmente baseado em microservices, e ao considerar utilizar uma arquitetura orientada a eventos, podemos escolher vários modelos e tecnologias. Descrevendo diferentes estilos de arquiteturas orientadas a eventos, David Dawson alega que requisitos não funcionais são o fator principal na escolha de como implementar uma arquitetura deste tipo.
-
Business Architecture: do negócio à TI, e não vice-versa
Em recente publicação, Mark Little defende a importância e a complexidade do desenho de aplicação em microservices, discutindo a necessidade de repensar a arquitetura dos dados. Dando mais um passo na direção que Mark indica ao falar em DDD, chega-se a uma mudança radical: estruturar a aplicação do ponto de vista do negócio, não da TI. A nova metodologia para isso é a Business Architecture.
-
Domain Driven Design e Microservices
Eric Evans, criador do DDD, sugeriu que o Domain Driven Design pode ser utilizado como mecanismo para gerenciar a "grande bola de lama" que pode surgir quando diversas equipes tentam integrar serviços de equipes externas.
-
Macro e micro arquitetura, DDD e CQRS
Começar um novo projeto escolhendo primeiro a tecnologia e framework, e então voltar-se para o problema do projeto, pode ser bastante perigoso. Jeppe Cramon falou em uma recente apresentação sobre macro e micro arquitetura, DDD e CQRS.
-
Os 10 enganos mais comuns no DDD que se deve evitar
Não interagir com especialistas do domínio é um dos enganos cometidos quando se utiliza DDD. Daniel Whittaker descreve 10 enganos que são cometidos regularmente pelos desenvolvedores.
-
Apache Isis: um framework Java para Domain-Driven Design
Conheça o Apache Isis, um framework Java para desenvolvimento rápido de aplicativos orientados a domínio, que cuida da persistência, segurança e interface com usuário, permitindo que os desenvolvedores foquem nos objetos de domínio.
-
Padrão de arquitetura CQRS: quando utilizar?
O padrão de arquitetura CQRS (Command Query Responsibility Segregation) vem recebendo destaque em vários blogs importantes, incluindo os de Martin Fowler e Udi Dahan. Além de rever os conceitos do padrão, esses autores analisam a sua aplicabilidade em várias situações e sua evolução ao longo do tempo.