BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Domain-Driven Design Content on InfoQ

Articles

RSS Feed
  • Using a DDD Approach for Validating Business Rules

    If the goal is to create software applications that emulate the behavior of domain experts, then the challenge is in capturing and implementing the business rules. This is more a factor of good knowledge management than it is raw coding ability. Following techniques from Domain-Driven Design can provide a structure for effectively validating and implementing business rules in a system.

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

  • Context is King: What's your Software's Operating Range?

    Francisco Torres shares from experience how users might change how one sees the context of a project and why it is important to define a software’s operating range: the set of quality properties in which a software system can successfully run.

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

  • There is a Cowboy in my Domain! - Implementing Domain Driven Design Review and Interview

    Implementing Domain Driven Design, has brought clarity to an important but little understood area of software design. As a measure of Software Design literature, Vaughn's work is educational and fun. With real world code samples and sage advice, IDDD guides the reader through the sometimes murky waters of DDD and helps them gain the insight required to start a DDD journey of their own.

  • Interview and Book Excerpt: Dan Haywood's Domain-Driven Design Using Naked Objects

    Domain-Driven Design Using Naked Objects book, by author Dan Haywood, covers the Domain-Driven Design topic using the open-source Java framework Naked Objects framework (which is now part of the Apache Isis incubator project). InfoQ spoke with Dan about the book, Naked Objects framework and its recent submission to be an Apache project.

  • Hades - JPA Repositories Done Right

    Almost every application has to access data to do its work. In a domain driven design approach one defines repositories for the entities that make up the domain. Java developers often use JPA to implement these repositories. Hades is an open source library that's built on top of JPA and Spring to significantly improve the implementation of data access layers by reducing the effort required.

  • A Discussion with Allard Buijze on CQRS with the Axon framework

    The Axon framework is a Java implementation of the Command and Query Responsibility Segregation. InfoQ talked with its creator, Allard Buijze, to find out more.

  • Strategic Domain Driven Design with Context Mapping

    Many approaches to object oriented modeling tend not to scale well when the applications grow in size and complexity. Context Mapping technique can be used to manage the complexity in large software development projects. In this article, author Alberto Brandolini discusses the many sides of bounded contexts and how to use them to build a context map to support key decisions in a software project.

  • Layered Architecture for Test Automation

    In test automation, code involved in testing is not only test logic, but also a bunch of other supporting code, like URL concatenation, XML parsing, UI, etc. Test logic can be buried in this unrelated code, which has nothing to do with test logic itself, making test code hard to read and maintain. In this article, the layered architecture of test automation is presented to solve this problem.

BT