Domain-driven design
Developing software models from the business domain together with the people who know its rules.
What is domain-driven design?
Domain-driven design, or DDD, grounds software modelling in a business domain. Domain experts and developers clarify terms, rules and relationships together. A shared language should carry the same meaning within a defined business context. Different contexts may need their own models; this boundary is often called a bounded context.
In a fictional business, sales uses “order” to mean a sold service, while the service team means a scheduled visit. Participants describe both meanings and their handover instead of silently assuming a single data model. This can lead to clearer software boundaries. DDD does not require microservices or a particular database type. How models are technically separated and operated is an additional architecture decision.
Sources
Related terms
- Software architectureFundamental decisions about a software system’s structure, interactions and quality goals.
- Modular monolithAn application deployed together with explicitly bounded internal modules and interfaces.
- Cache stampedeA cache stampede occurs when concurrent cache misses trigger the same expensive calculation or data query repeatedly.
- BackpressureBackpressure adjusts incoming data to the receiver’s processing capacity through signals to slow down or pause.
- Race conditionA result depends on the timing of overlapping accesses and can therefore be wrong.
- Memory leakMemory that is no longer needed stays allocated while the program runs.
Articles on this topic
Your project with ASES
Describe your project to us. We will get back to you with an initial assessment.