BT

Início Domain Driven Design no InfoQ Brasil

Notícias

Feed RSS
  • 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.

BT

Seu cadastro no InfoQ está atualizado? Poderia rever suas informações?

Nota: se você alterar seu email, receberá uma mensagem de confirmação

Nome da empresa:
Cargo/papel na empresa:
Tamanho da empresa:
País:
Estado:
Você vai receber um email para validação do novo endereço. Esta janela pop-up fechará em instantes.