DDD - Domain Driven Design - Architecture

Architecture in DDD

Reading Time: 3 minutes

In the “what-is-ddd” article, I explained that DDD is initially adopted as a set of standards and good software development practices, remember that strategically designed and tactically designed Domain Models must be architecturally neutral.

One of the great advantages of DDD is that it does not require the use of any specific architecture.

When implementing DDD, you will have to define an architecture at some point, my intention is to show that you are free to adopt any type of architecture that makes sense to you, and may even use different types of architecture.

It is important to understand that each Delimited Context can implement a specific architecture.

Below I will briefly outline some of the architectural possibilities, models and patterns that can be used in your DDD project:

Layered Architecture

Layered Architecture is undoubtedly the most popular and most used architecture by today’s developers.
Layers are a form of separation of responsibilities, meaning each layer has a specific responsibility.
An upper layer can access a lower layer, but a lower layer can never access an upper layer.

Hexagonal Architecture

Hexagonal Architecture [Alistair Cockburn] is also known as Ports and Adapters, where, Ports are the interfaces and Adapters are the implementations, it is a type of architecture where the domain layer is emphasized. In a practical way, we can understand how a layered architecture where the ‘Dependency Inversion Principle‘ was applied so that the domain layer became the central layer that does not ‘depend’ on any other layer.

REST

Representational State Transfer, abbreviated as REST, is an architectural style for designing distributed software architectures, REST defines a set of HTTP-based properties and constraints, and uses the full potential of HTTP verbs.

CQRS

Command Query Responsibility Segregation, or CQRS, is a standard software architecture that separates reading and writing from data, where, Query is for reading and Command for writing data.

Event Oriented Architecture

The event-driven architecture (EDA) is a software architecture, where there are Producers (Pub) of events that generate a flow of events, and Consumers (Sub) of events that listen to events.

Actor Model

The actor model is a paradigm of reactive programming used to create distributed and concurrent applications, where an actor is a fundamental unit of computation.

These are just a few possibilities, there are many others not listed here. Everything will depend on your need, and how much you can invest in your project.

In his book [Vaughn Vernon] quotes that sometimes we are tempted to put too much emphasis on architecture, instead of putting more emphasis on the domain model, the domain model adds more business value and will be more enduring. Architecture is important, but remember that architectural influences come and go.

Buy Me A Coffee

Leave a Comment

Your email address will not be published.