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

  • Domain-Driven Design the Wrong Way

    Applications claimed to have been built using Domain-Driven Design (DDD) in reality often consists of entities or DTOs separating data and logic together with services containing a mix of business and infrastructure logic, Gabriel Schenker states, noting that this also often applies early on to projects building new applications. Lack of knowledge is one major reason for this, Schenker believes.

  • Avoid a Canonical Data Model

    Standardizing on common models for business objects that are exchanged within an enterprise, e.g. Customer, Order and Product together with the attributes and associations they have, might seem compelling but for Stefan Tilkov this creation of Canonical Data Models (CDMs) is a horrible idea which he strongly advices against.

  • Clarifying Domain-Driven Design Using a Trading Application Example

    Domain-Driven Design (DDD) is an approach to building software emphasizing collaboration between domain experts, developers and others involved in order to meet business objectives, Naresh Bhatia explains introducing the DDD base concepts exemplifying with Bullsfirst, an example system of medium complexity from the financial trading domain.

  • The Benefits of Microservices

    Gene Kim (moderator), Gary Gruver, Andrew Phillips and Randy Shoup have discussed some of the benefits of microservices in a recent online panel.

  • Behaviour-Driven Development Combined with Domain-Driven Design

    Behaviour-Driven Development (BDD) is very much about conversations and examples but there is a software design part that can be used to bring BDD and Domain-Driven Design (DDD) practices together, combining the conversional bits with a domain-focused design activity, Konstantin Kudryashov explains in a presentation.

  • Aggregates, Entities and Value Objects in Domain-Driven Design

    Move as much as possible of the behaviour away from the Entities into Value Objects when working with Aggregates, As more behaviour is needed this is added as new value objects, Paul Rayner recommends in a series of blog posts covering aggregates, entities and value objects, all concepts from Domain-Driven Design (DDD).

  • Sharing Data Between Bounded Contexts in Domain-Driven Design

    When using Domain-Driven Design (DDD) separating the concerns of a large system into bounded contexts with each context using its own data store there is often a need to share some common data. One way of doing that is to let each context publish events about changes, events that others can listen to, Julie Lerman recently explained in MSDN Magazine.

  • Exploring the Hexagonal Architecture

    Layered systems are an architectural style used essentially to avoid coupling, the biggest enemy of software maintainability, with Ports and Adapters, or a Hexagonal Architecture, an example of such an architecture, Ian Cooper explains in a presentation about architecture styles, specifically the Hexagonal Architecture.

  • Domain-Driven Design with Onion Architecture

    Domain-Driven Design (DDD) together with Onion Architecture is a combination that Wade Waldron believes has increased his code quality dramatically since he started using it a few years back. Using DDD was a kick-off but together with Onion architecture he found his code to be more readable and understandable, and far easier to maintain.

  • Experiences Building a Reactive Event-Driven CQRS Application

    CQRS and Event Sourcing provide a clear and concise way to build distributed applications that adhere to the reactive manifesto, Duncan DeVore claimed in a recent presentation sharing his experiences building a distributed application using Akka and Scala.

  • Patterns for Building and Deploying Microservices

    Managing micro-services means looking after lots of small systems talking to each other and automated provisioning as well as infrastructure automation is crucial, James Lewis states when sharing techniques and practices that have helped him manage the increased operational complexity a microservice architecture gives.

  • Moving from a Monolith to Microservices at SoundCloud

    Moving SoundCloud into a microservices architecture has been essential in enabling our teams to develop production-ready features with much shorter feedback cycles, Phil Calçado writes in a three-part series sharing their experiences moving away from a monolithic system.

  • Building a Reactive DDD and CQRS Based Application Using Akka

    DDD and CQRS are great for building scalable software considering concepts like bounded contexts, transaction boundaries and event based communication and is together with Akka a complete platform for building enterprise applications, Pawel Kaczor starts a three-part series building an reactive application based on these concepts.

  • Domain Modelling Using Event Storming

    By gathering all domain experts and developers in a room, provide them with a paper roll, lots of colored post-its and a facilitator they may in hours create the best model ever, Alberto Brandolini suggested at the recent DDD Exchange conference in London.

  • Greg Young: Scheduling for Things to Happen in the Future

    Delay of message sending into the future is a very powerful pattern and is often the preferable way of dealing with temporal problems compared to batch job that will run a query on the domain model and update some aggregates, Greg Young explained at the recent DDD Exchange conference in London.

BT