Domain Driven Design
24 items tagged with "domain-driven-design"
Best Practices2
Hexagonal Architecture (Ports and Adapters)
An architecture that isolates core application logic behind ports, with adapters connecting external concerns like databases and UIs, so the core stays independent of technology.
Domain-Driven Design (DDD)
A software design approach that models complex business domains in code, using a shared language and bounded contexts to align software structure with the business it serves.
Patterns6
Specification
Encapsulates a business rule as a reusable, combinable predicate object that tells whether a candidate satisfies the rule.
Repository
Mediates between the domain and data mapping layers via a collection-like interface for accessing domain objects, hiding persistence details.
Unit of Work
Tracks objects affected by a business transaction and coordinates writing out changes and resolving concurrency as a single commit.
Data Mapper
Moves data between objects and a database while keeping them independent, so domain objects carry no persistence knowledge.
Value Object
Models a concept defined by its attributes rather than identity, making it immutable and compared by value to keep the domain expressive and safe.
Domain Event
Captures something significant that happened in the domain as an explicit object, decoupling the trigger from the reactions to it.
Anti-Patterns7
Anemic Domain Model
Domain objects that hold data but no behavior, with all logic pushed into separate service classes, draining the object model of its purpose.
Smart UI
Concentrating business logic, data access, and rules inside the presentation layer, fusing UI and domain so neither can change or be tested independently.
Entity Service
Designing microservices around data entities rather than business capabilities, forcing every workflow to orchestrate chatty calls across CRUD-only services.
Leaky API Abstraction
An API that exposes internal database schemas, implementation details, or storage structures, coupling clients to internals and blocking safe evolution.
Nanoservices (Overly Fine-Grained Services)
Splitting a system into so many trivially small services that coordination, network, and operational overhead dwarf any benefit of separation.
Entity Services
Decomposing microservices around data entities (CRUD wrappers per table) rather than business capabilities, creating chatty, anemic, tightly coupled services.
Death Star (Distributed Big Ball of Mud)
A microservice estate where every service calls nearly every other with no clear boundaries, producing a tangled mesh impossible to change or reason about.
Blueprints3
Modular Monolith to Microservices Blueprint
Decompose a modular monolith into independently deployable microservices using the strangler fig pattern and database-per-service.
Big Ball of Mud to Modular Monolith Blueprint
Restructure a tangled monolith into a modular monolith with enforced module boundaries before considering any service split.
Central Orchestration to Choreography (Saga) Blueprint
Replace a central orchestrator coordinating distributed transactions with event-driven choreography using the saga pattern and compensations.
Playbooks3
Monolith Decomposition Program Playbook
A phased program for breaking a large backend monolith into independently deployable services using the strangler-fig approach.
Domain-Driven Decomposition Program Playbook
A program that uses domain-driven design and event storming to decompose a system into bounded-context services aligned to teams.
Modular Monolith Adoption Program Playbook
A program to restructure a tangled monolith into a modular monolith with enforced boundaries before any service extraction.
Glossaries2
Bounded Context
A central pattern in Domain-Driven Design that defines clear boundaries within which a model is defined
Domain-Driven Design
Domain-driven design (DDD) is a software design approach that models software closely on the business domain, using a shared language between developers and domain experts and organizing the system around bounded contexts.