BT

InfoQ Homepage Domain Driven Design Content on InfoQ

  • The Value and Purpose of a Test Coach

    Introducing business-oriented automated testing can involve a huge cultural change. For this we really need a Test Coach role, just like we have agile coaches and scrum masters. In this article we hear from someone living this new role, using Domain Oriented Testing on a daily basis to ensure acceptance tests have full story coverage, and unit tests verify business behavior, not implementation.

  • Modeling Uncertainty with Reactive DDD

    Vaughn Vernon has written several books on DDD and reactive messaging patterns, and has found that the nature of distributed systems means you must deal with uncertainty. How to respond to a missing message, or a message that is received twice, should be a business decision, and therefore must be part of the domain model.

  • The DDD Do-Over

    Jimmy Bogard had a rare opportunity to do what many developers want after finishing a tough project -- a do-over. His team worked on two very similar projects, both using DDD. He discusses the lessons learned from the first project and how the team avoided common pitfalls and was more successful on their later project.

  • Refactoring to a Deeper Model

    Paul Rayner uses a case study to demonstrate how refactoring your code can lead to a deeper understanding of your domain model. Through common code refactorings, combined with the implementation of patterns, the codebase became more cohesive and easier to reason about, reducing the time to perform some common tasks from weeks or months to just hours.

  • DDD With TLC

    At the 2017 Explore DDD conference, Julie Lerman, a self-described Serial DDD Advocate, spoke about how to approach Domain-Driven Design with Tender Loving Care. InfoQ sat down with Lerman to ask about how she introduces DDD to new clients, and helps them be successful.

  • The SOA Journey: from Understanding Business to Agile Architecture

     If your monolith is tightly coupled and not cohesive, you could split it in order for a business to be more agile.  There are a lot of wrong ways that you can do that. They result in the same tightly coupled and non-cohesive monolith, but which is distributed across a network. This article examines how you can align your technical services and business-capabilities.

  • Perspective on Architectural Fitness of Microservices

    In this article we peel the onion of potential architectural fitness of microservices in the context of Master Data Management, and the challenges a microservices-based architecture may face when solving problem domains that require compute-intensive tasks, such as the calculation of expected losses on a portfolio of unsecured consumer credit.

  • Self Contained Systems (SCS): Microservices Done Right

    Everybody seems to be building microservices these days. There are many different ways to split a system into microservices, and there appears to be little agreement about what microservices actually are - except for the fact that they can be deployed independently. Self-contained Systems are one approach that has been used by a large number of projects.

  • Developing Transactional Microservices Using Aggregates, Event Sourcing and CQRS - Part 2

    This article concludes the description of a way to develop microservices using Domain Driven Design, Event Sourcing and Command Query Responsibility Segregation (CQRS). The practical considerations and benefits of this approach are compared with other options.

  • Developing Transactional Microservices Using Aggregates, Event Sourcing and CQRS - Part 1

    Developing transactional business applications using the microservice architecture is challenging, because domain models, transactions and queries are resistant to functional decomposition. This article describes a way to develop microservices that solves these problems by using Domain Driven Design, Event Sourcing and Command Query Responsibility Segregation (CQRS).

  • CQRS for Enterprise Web Development: What's in it for Business?

    With a focus on the business case for a CQRS architecture, this article covers the core concepts of Command Query Responsibility Segregation, and contrasts them with a common, n-tier architecture. Benefits including scalability and maintainability are highlighted, which can reduce the total cost of ownership, and lead to an improved return on investment when choosing a CQRS architecture.

  • Reactive Messaging Patterns with the Actor Model Book Review and Q&A with Vaughn Vernon

    Vaughn Vernon in his new book Reactive Messaging Patterns with the Actor Model shows how this model can simplify enterprise software development. After an introduction to the basics of the actor model and tutorials on Scala and Akka the rest of the book is a patterns catalogue describing most of the patterns in the book Enterprise Integration Patterns from an actor model perspective.

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.