About this chapter
Domain-Driven Design has two halves. This chapter covers the strategic half - the big-picture decisions about language and boundaries you make before writing a single class. You'll learn why software should be shaped around the business domain, how a shared ubiquitous language removes whole classes of bugs, how bounded contexts let the same word mean different things in different places, how to draw a context map of the relationships between them, and how to spot the core domain worth your best effort. The code building blocks (entities, value objects, aggregates) come in the next chapter.
Lessons from courses
- 1 What is Domain-Driven Design Domain-Driven Design explained for developers: shaping software around the business domain and its language, strategic vs tactical DDD, and when it is worth it.
- 2 Ubiquitous language The ubiquitous language in Domain-Driven Design: one shared vocabulary between domain experts and code. How mismatched words cause bugs, with PHP examples.
- 3 Bounded contexts A bounded context is a boundary where a model and its language stay consistent. See how the same word like Customer means different things in different contexts.
- 4 Context mapping Context mapping in DDD: partnership, shared kernel, customer/supplier, conformist, anticorruption layer (ACL) and open host service, with a simple example map.
- 5 Subdomains: core, supporting, generic DDD subdomains explained: core, supporting and generic. Learn where to invest your best design effort, and what to buy or simplify instead of building.