Learning Domain-Driven Design — Chapter 1

Alexander introduces the author: he saw Vlad at an architecture conference in Berlin in 2019 and summarised his report, which later grew into this book — twice the chapters, plus a new part comparing DDD with other methodologies. The book opens with a recognisable scene: a newcomer is shown controllers and repositories, then a class full of conditions, and told "and this is the business logic". Alexander recalls that early in his career patterns seemed most important, although what matters is that code solves a business problem — that is where a company differs from competitors. The first part of the book answers "what and why", and in his words it alone can advance a career better than yet another technical book. Ilya then works through the three subdomain types — core, generic, supporting — using the chapter's closing table: complexity, rate of change, where to implement, whether it gives a competitive advantage.

The example is deliberately simple: for a bakery the core is the pastry itself and why people come here; shelf display is a supporting subdomain with real but obvious expertise; payroll and flour delivery are generic problems that are cheaper to buy and easy to outsource. Ilya found the line between generic and supporting the hardest until he met the example that writing a controller is supporting work: you cannot buy it, but you have to do it. Alexander adds that the types are not nailed down: what starts as support turns into a product for others when done well, and Vova brings up EPAM with its internal Telescope tool for finding people and tracking allocation, which the company now sells to clients. The reverse trap is named too: a quick admin panel on a generic solution accumulates customisations until switching to the off-the-shelf option is no longer possible. An important note of the chapter — subdomains are discovered, not designed, often starting from the company structure, which echoes Conway's law.

The second chapter, on language, opens with the broken telephone: the expert passes knowledge to an analyst, the analyst to requirements, the requirements to developers, and everyone works with their own mental model, so you can solve the wrong problem perfectly. Vova confirms with a live example: a business idea that passes through many stages ends up unrecognisable unless a shared model is maintained. Vlad calls systems analysts a dysfunction, and Alexander partly agrees — he believes in business and engineering working together — but Ilya defends them: analysts make life much easier, as long as the domain stays transparent to everyone and communication does not close on one role. The book's tools are a glossary, everyone contributing to the language, and caution with Gherkin tests, which often degrade into a low-level test language. Alexander stresses that the ubiquitous language has no technical terms: it is a refined language of the domain, without databases and queues. Two stories illustrate the point: clients who learned to run Python code after two years of daily meetings, and a monitoring system that called one entity both an agent and a probe until the code got tangled.

The participants find the Russian translation — literally "single" — an imprecise rendering of ubiquitous and recall Philip K. Dick's Ubik: "omnipresent" is stronger. Alexander links this to a common mistake: people who do not reach the third chapter stretch one language over the whole company. He shows bounded contexts on an "application": in lending it is a loan application, in the business line an application to start working with a partner, in cash management an application for an account; and inside online acquisition, which he runs, it grows from a short form with a name and phone number into a completed, scored record in the warehouse with product delivery statuses. Unifying that is a fiasco, while explicit boundaries and transitions work. Ilya adds the book's Catch-22, the two traditional escapes — one model for everything or prefixes — and the map analogy: there are many maps, and the task needs the minimal model, like a piece of cardboard instead of a fridge. Vova sees the same problem as documenting architecture through different views. The team rule is unambiguous: two teams do not work on one context; Alexander recalls once physically splitting a monolith for exactly that reason.

The fourth chapter is about how contexts interact, and Vova opens with the partnership group of patterns: a partnership as ad hoc agreements that require constant communication, and a shared kernel on the example of T-Bank lending, where acquisition and collection have different federal laws and channels but a shared model of the customer, the company, and scoring, which a third team may own through a CRM. Alexander arranges the remaining patterns by the balance of power between supplier and consumer: if the supplier holds it — "take it or leave it" — the consumer is either a conformist accepting a foreign model or puts up an anti-corruption layer that translates the external model into its own and absorbs compatible changes; if the consumer holds it, the supplier becomes an open host and publishes a language — a diplomatic one that may differ per consumer.

Ilya adds examples: you become a conformist before a state registry whose contract you cannot influence; an anti-corruption layer is a mapper from a legacy system into your own model; an open host resembles a gateway that gathers information and serves it in a convenient contract, with versioning that lets consumers migrate gradually. Vova adds that the anti-corruption layer or the published language is what protects the core — the most competitive business logic. The third option is to go separate ways and duplicate a small piece of logic if integration would be excessive. All of it is drawn on a context map; Alexander notes that in the first version the map was a separate chapter and the patterns sat in the tactical part, and the author eventually rewrote the book from scratch. From the audience: has anyone seen proper DDD in a project? Ilya has mostly seen ruined ones, where the team changed and the language was lost; the club plans to invite Vlad to a sixth session and collect questions under the recordings. Alexander reminds that the author's own domain is advertising auctions, which cannot be understood without a strict language.