Domain-driven design
Domain-driven design is a software design approach that centers models, structure, and terminology on the concepts, behavior, and boundaries of a problem domain.
Architecture Modernization: Socio-technical alignment of software, strategy, and structure
Domain-driven design is a software design approach that models software around the concepts, rules, and boundaries of a business domain.
- How it is used
- Aligns business-domain models, software boundaries, and team ownership to make change less coupled.
- How deep it goes
- Shows collaborative modeling and bounded-context adoption through cases, but does not provide a complete DDD implementation recipe.
- Examples
- Uses marketplace category expansion, country-specific gigs-platform onboarding, and cross-functional payroll-domain discussions.
- What you can do after
- Practice/perform it through collaborative modeling and EventStorming to identify domain boundaries before changing software and team ownership.
Collaborative Software Design: How to facilitate domain modeling decisions
A software design approach that centers development on a model of the business domain and uses that model to guide software structure and implementation.
- How it is used
- Guides complex-domain software design by aligning stakeholders around a shared model, language, and set of explicit boundaries.
- How deep it goes
- Explains principles, strategic and tactical scopes, language, models, and boundaries, but leaves the exact method for achieving understanding open.
- Examples
- Uses collaborative visualization and a Payments bounded context to illustrate shared modeling and the importance of generic subdomains.
- What you can do after
- Evaluate/understand complex business problems before designing software, then organize models, language, boundaries, and implementation around that understanding.
Automating API Delivery
Domain-driven design is an approach to software design that centers the structure and language of software on the underlying business domain.
- How it is used
- Guides API designers in modeling business operations and data before translating the design into API definition changes.
- How deep it goes
- Defines domain models, ubiquitous language, and bounded contexts, then stops at conceptual API modeling and OpenAPI translation.
- Examples
- Uses business operations, data models, user journeys, and API model changes as design-review artifacts.
- What you can do after
- Evaluate API models against bounded contexts and domain principles before implementing consistent API definitions.
Read how Automating API Delivery explains domain-driven design →
Go in Action, Second Edition
Domain-Driven Design is a software design approach that structures software around real-world business concepts and domain behavior.
- How it is used
- Structures larger Go projects around shared business concepts that API and worker services can use without tight coupling.
- How deep it goes
- Defines entities, interfaces, and dependency direction, then connects them to hexagonal architecture and testable implementations.
- Examples
- Uses an RSS reader with Article, Feed, Fetcher, ArticleReader, Storage, API, and worker components.
- What you can do after
- Build shared domain boundaries, swap interface implementations, and test handlers without databases or external services.
Read how Go in Action, Second Edition explains domain-driven design →
Effective Platform Engineering
Domain-driven design is a software design approach that centers the structure and behavior of software on the underlying business domain and its models.
- How it is used
- Organizes platform delivery around independent domain teams and user experience rather than traditional functional departments.
- How deep it goes
- Explains domain boundaries, ownership, dependencies, and coordination smells, without specifying detailed implementation mechanics.
- Examples
- Uses independent domain teams, separate backlogs, cross-team communication as a smell, and platform domain figures as examples.
- What you can do after
- Evaluate platform boundaries and team interactions for independent delivery, manageable dependencies, and a smooth user experience.
Read how Effective Platform Engineering explains domain-driven design →
Bootstrapping Microservices, Second Edition: With Docker, Kubernetes, GitHub Actions, and Terraform
Domain-driven design is a software design approach that models software around the concepts and boundaries of its problem domain.
- How it is used
- Models business domains to decide what belongs inside each microservice.
- How deep it goes
- Defines bounded contexts and applies them to service boundaries, but stops short of detailed implementation procedures.
- Examples
- Uses a video-streaming domain containing User, Like, and Video across recommendation and video-storage services.
- What you can do after
- Build it from scratch by modeling domain boundaries and mapping bounded contexts to microservices.
Functional Design and Architecture: Examples in Haskell
Domain-driven design is a software development methodology that centers software design on the concepts, relationships, and rules of the problem domain.
- How it is used
- Centers software design on domain concepts and business rules to make complex logic clear, maintainable, and easier to reason about.
- How deep it goes
- Develops domain modeling through abstractions, algebraic data types, embedded DSLs, organization, and decoupling rather than detailed implementation recipes.
- Examples
- Uses algebraic data types, interpretable embedded DSLs, runtime objects, and interfaces as domain-modeling artifacts.
- What you can do after
- Build domain-specific languages that encode business rules, restrict invalid operations, and organize domain complexity.
Read how Functional Design and Architecture: Examples in Haskell explains domain-driven design →
Related concepts
- ubiquitous languageuses · Ubiquitous language is a shared, precise vocabulary that domain experts and software practitioners use consistently to describe a domain and its concepts.
- domain modeluses · A domain model is a software representation of the concepts, entities, relationships, rules, and behavior of a problem or business domain.
- microservice architectureuses · Microservice architecture is a software architectural style that organizes an application as independently deployable services with focused responsibilities that communicate through defined interfaces.
- complexityaddresses · Complexity is the degree of difficulty in understanding, analyzing, changing, or operating a system or problem, arising from its structure, behavior, or interacting parts.
- software design EventStorminguses · Software design EventStorming is a collaborative modeling technique that explores domain events and processes to inform software structure and behavior.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.