DDD

Domain Driven Design

Domain Driven Design (DDD) is a set of principles and modeling techniques that can help with the design of complex software systems. This is especially relevant to software that needs to express complex business logic as code.

DDD is independent of programming paradigms and even system architecture. The architecture and tech stack should be determined by DDD and not the other way around.

Why invest in DDD?

You can either have good design or bad design but not no design. Effort not invested in good design ends up being paid back as tech debt years later when the whole application needs to be rebuilt because it has turned into a big ball of mud.

Strategic Design

This is the high level design that breaks down the complex domain of a business into manageable parts.

Ubiquitous Language

To effectively express the business problem that the software is addressing, the same language should be shared between business people and technical people. This is known as ubiquitous language.

Using a ubiquitous language has several benefits:

• The business logic is directly represented in code. This avoids communication gaps between business and IT.
• Talking in terms of specifics of the business instead of using general terms avoids wrong assumptions during development.
• Product owners or business analysts can write executable text-based tests in the BDD style which can serve as a proof that the software behaves as the business expects.

Developers should put effort into asking more questions to the domain experts about business processes even if they are quite silly and the developers have experience in developing solutions for other companies operating in the same domain.

Bounded Contexts

A bounded context encloses a semantic context within a boundary. The ubiquitous language inside one bounded context differs from that in another bounded context. For example, the same words might mean different things in different bounded contexts. They are like European countries or states in India - each having its own language.

Bounded contexts are in the problem space when doing domain modeling but they can translate into independent software artifacts in the solution space. Each bounded context should be developed by one team. One team might develop software in multiple bounded contexts but multiple teams should never work on one bounded context.

Domain Driven Architecture Models

This is a non-exhaustive list of architecture models that can work with DDD.

• Event Driven Architectures incl. Event Sourcing
• Ports and Adapters
• Reactive systems using the Actor Model
• Microservices
• Serverless

A bounded context might practically manifest as one microservice or one node in an actor system etc. For monolithic applications, a package (like in Java) can act as a bounded context.

Subdomains

A subdomain exists in one bounded context. A subdomain represents a single logically separable domain model. Each subdomain might have its own domain experts who specialize in it.

The subdomain that represents the most important competency of your business is known as a Core Domain. This is usually developed in-house.

A Supporting Subdomain isn't the primary reason why a business exists but it helps support the business processes. This can be out-sourced.

A Generic Subdomain solves a general (usually administrative problems like HR, accounting etc.) for the business. From a strategic perspective, Buy is usually better than Build for this kind of subdomain.

Context-Mapping

This is an exercise in connecting together subdomains enclosed in bounded contexts.