---
title: "Domain-driven design | Skills We Assign For | Azendo"
description: "Domain-driven design on long-lived systems — bounded contexts, shared language, and the Azendo roles assigned for it."
url: "https://azendo.co/skills/domain-driven-design/"
---

[Skills](https://azendo.co/skills/) Architecture and patterns 

# Domain-driven design.

Domain-driven design is an approach that puts the business domain at the centre of the model: shared vocabulary between specialists and domain experts, explicit boundaries between subdomains, and code whose structure reflects the business rather than the framework.

## Where Domain-driven design fits on a long engagement.

The durable parts of DDD are the cheapest to adopt. A shared vocabulary where the code uses the same word as the business, and explicit boundaries where one subdomain ends and another begins, deliver most of the value. The tactical patterns are useful in the complex core and mostly ceremony everywhere else.

The common failure is applying the full pattern set uniformly across a system where only one area is complex. Aggregates and repositories around simple CRUD produce ceremony without benefit, and it discredits the approach with the team. DDD is a way of deciding where to spend modelling effort, not an instruction to spend it evenly.

## What an assigned team does with Domain-driven design.

DDD depends on continuous contact between the people writing the code and the people who understand the domain. That relationship is built over quarters, not sprints, and it is the first thing lost when capacity rotates — the vocabulary survives in the code but the understanding behind it does not.

Specialists staying on one domain long enough to argue with an expert about it is the mechanism that makes this work, which is the case for a [dedicated software development team](https://azendo.co/services/dedicated-development-team/) rather than capacity assembled per project.

## What we use Domain-driven design for.

* Complex rules nobody has written down Domain logic captured in a model that experts can read, instead of scattered through controllers and jobs.
* Deciding where to split a monolith Bounded contexts used to find seams that follow the business, rather than splitting on technical convenience.
* Vocabulary that survives handover Code using the same terms as the business, so a new specialist learns one language rather than two.

## How Domain-driven design capacity is assigned.

Domain modelling capacity is assigned under [outsource software development services](https://azendo.co/services/software-development/), with access to your domain experts treated as a delivery dependency rather than an optional extra.

## Roles we assign Domain-driven design for

* [Software Architect Software development](https://azendo.co/services/software-development/software-architect/)

## Service lines it sits in

* [Software development](https://azendo.co/services/software-development/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in architecture and patterns

* [event-driven architecture — skill we assign for](https://azendo.co/skills/event-driven-architecture/)
* [microservices and modular monoliths — skill we assign for](https://azendo.co/skills/microservices-and-modular-monoliths/)
* [AWS and Azure reference architectures — skill we assign for](https://azendo.co/skills/aws-and-azure-reference-architectures/)
* [Double-entry ledgers — skill we assign for](https://azendo.co/skills/double-entry-ledgers/)
* [Multi-tenant architecture — skill we assign for](https://azendo.co/skills/multi-tenant-architecture/)
* [CQRS — skill we assign for](https://azendo.co/skills/cqrs/)

## Tell us what your roadmap needs Domain-driven design for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)