The lecture begins by taking stock of what a master's student already possesses. You know programming, in many programming languages. You know object-oriented programming and design patterns. You know software architectures and design principles. You know software engineering best practices. The inventory is deliberately flattering, because it sets up the embarrassment:
What is the criterion to choose if and when to adopt languages / patterns / architectures / principles / practices?
Without a criterion, a design decision is an aesthetic preference wearing a technical vocabulary. The recommended workflow — Problem → Model → Architecture → Solution, with analysis and design as the two decisive arrows — localises the missing criterion precisely: it is needed to derive the model. Everything downstream (which pattern, which architecture, which library) becomes a consequence rather than a taste, once the model is anchored to something outside the developer's head.
That something is the domain.
Domain-Driven Design (DDD) is presented honestly as one of many approaches to software design. What distinguishes it is not a notation but a composition: it consists of principles, best practices and patterns leading design, unified under a common philosophy, and its focus is on the design workflow rather than only on the result.
The lecture lists four major benefits, and it is worth reading them as four different kinds of pay-off:
| Benefit | Kind of pay-off |
|---|---|
| It stresses adherence to the problem at hand | Correctness: the software solves the actual problem, not an adjacent one that was easier to formalise |
| It focuses on delivering a business-tailored model, and therefore a business-tailored solution | Value: the model is an asset of the business, not only of the code base |
| It harmonises communication among managers, technicians and users | Organisational: fewer translations, therefore fewer translation errors |
| It stresses the production of maintainable and extensible software | Temporal: the cost of the next change, not only of this one |
DDD is a workflow discipline before it is a catalogue of patterns. The building blocks of Chapter 3 and the integrity patterns of Chapter 4 only make sense as the tail of a process that starts by listening to how the domain talks about itself.
The second half is the demanding one. Matching a domain once, at analysis time, is an exercise; keeping the match while the code base and the business both move is an architectural constraint. That constraint is precisely what motivates bounded contexts, the model-integrity patterns and the hexagonal architecture in Chapter 4.
Four terms carry the whole framework. The lecture defines them tersely; the tabs below keep the original wording and add the remarks made alongside it.
A well-established sphere of knowledge, influence or activity; equivalently, the subject area to which the user applies the software.
Two remarks accompany the definition, and they are the whole point: the focus is on how users and experts perceive the domain, and the focus is not on how developers perceive it.
Examples given: a university, a given company, linear algebra, machine learning.
A portion of the domain with a clear boundary, which:
Examples: departments, divisions, complex numbers.
A set of software abstractions mapping relevant concepts of the domain — equivalently, a reification of the domain in software.
Concretely: Java/Kotlin/Scala projects, packages, interfaces, classes, records, methods.
A language structured around the domain model, used by all people involved in the domain, which should be used in the software in such a way that its semantics is preserved.
Underlying assumption: different people call the same things differently, especially when they come from different contexts. It is commonly reified into a glossary of terms and used to name software components.
The ubiquitous language is the mechanism that makes "mirror the domain" operational. Its assumption is sociological rather than technical: different people call the same things differently, especially when they come from different contexts. Left alone, a project accumulates three parallel vocabularies — the users', the managers', the developers' — and every conversation pays a translation tax, with interest charged as defects.
DDD refuses the tax by declaring one language and using it everywhere: in meetings, in the glossary, and in the identifiers of the code. Two operational consequences follow directly from the slides:
UserKey.The lecture is also explicit about how the language is obtained: interaction with experts is essential, and the conceptual workflow (next section) insists that you must not assume you already know what words mean.
The lecture gives the workflow as an ordered list. It is short enough to memorise and specific enough to follow on a real project.
Step 3 is where most of the intellectual work happens, and it is also the step with an explicit prohibition attached. Common sense is not a shortcut to a domain: it is the mechanism by which a developer silently substitutes their own meaning for the expert's and then discovers the discrepancy in production.
Step 5 produces the context map: a map of all the contexts in a domain and their boundaries, their points of contact, their dependencies, homonyms and false friends — providing the whole picture of the domain. A context boundary is worth making explicit from several perspectives: technical (dependencies among classes and interfaces), physical (a common database, common facilities) and organisational (the people or teams maintaining or using the code).
The rule of thumb 1 concept ≈ 1 interface turns the glossary into a package. Below is the customer fragment used throughout the DDD lecture, written as Java interfaces. Read it as a translation exercise: every identifier is a word that a domain expert would recognise, and no identifier is a word that only a programmer would use.
Two details in that fragment already anticipate Chapter 3. First, Customer exposes a getter for its identifier and setters for name and email: it is a thing with an identity that survives changes to its attributes. Second, TaxCode and VatNumber are both kinds of CustomerID: they are pure values, distinguishable only by what they contain. That distinction — identity versus value — is the first building block of the next chapter.
Be ready to recite the four notions with their one-line definitions (domain, context, model, ubiquitous language), the six steps of the conceptual workflow, and the difference between homonyms and synonyms. Then be ready to justify the rule of thumb 1 concept ≈ 1 interface: an interface is the smallest software artefact that can carry a name and a contract without committing to an implementation, which is exactly what a glossary entry is.
A well-established sphere of knowledge, influence or activity; the subject area to which the user applies the software. The remarks: the focus is on how users and experts perceive the domain, and it is not on how developers perceive it.
A clear boundary. A context relies on a sub-set of the concepts of the domain, is a place where words and names have a unique, precise meaning, and is clearly distinguishable from other contexts. Departments, divisions, or "complex numbers" inside linear algebra are the examples given.
Because meaning is relative to a domain, and the same word may mean different things in different domains and in different contexts of the same domain. This is not a philosophical aside: it is the justification for the glossary, for the context map, and for treating homonyms and false friends as first-class design information.
Homonyms: similar names, different meanings — dangerous because two teams believe they agree when they do not. Synonyms: different names, similar meanings — dangerous because the model duplicates one concept into two types, and the duplication drifts. Both are discovered by interacting with experts and recorded in the glossary and on the context map.
(1) Identify and name the domain; (2) identify and name the main contexts; (3) identify the actual meaning of relevant words and track them in a glossary, without relying on common sense; (4) adhere to the language and sketch code mirroring it; (5) draw a context map with contexts, junctions and varying words; (6) model the software around the ubiquitous language, one concept per interface.
A map of all the contexts in a domain, their boundaries and their points of contact (dependencies, homonyms, false friends), providing the whole picture of the domain. A boundary matters technically (dependencies among classes and interfaces), physically (common database, common facilities) and organizationally (people and teams maintaining or using the code).
That adherence survives change. Architecture and implementation must favour adherence in spite of their own evolution and modification, which means change must be localised: this is the motivation for bounded contexts and for the model-integrity patterns studied in Chapter 4.
Everywhere: in the speech of everyone involved in the domain, in the glossary that reifies it, in the names of the software components, and in the functionalities and UX that users experience. The requirement is that the semantics is preserved at each of these appearances.
Because the choice of software construct depends on the nature of the concept and on what the programming language offers: a concept may become a class, an interface, a structure, a record or an ADT. The rule fixes the granularity (do not merge two domain concepts into one type, do not scatter one concept across many), not the construct.
Adherence to the problem at hand; a business-tailored model and therefore a business-tailored solution; harmonised communication among managers, technicians and users; and an emphasis on maintainable and extensible software.