Learning Domain-Driven Design — Conversation with Vlad Khononov

Vlad introduces himself briefly: two years of struggling with the book, everything he knows about DDD is in it, and the approach once changed the trajectory of his career. To a listener's "why not Evans": nobody has cancelled Evans — it is the black-belt book, and finishing it in the original feels like unlocking an achievement. His goal was something readable in an hour: hence the O'Reilly report, eighty pages, an exclusive for subscribers, printed as merchandise for conferences in Berlin and New York — in Berlin in 2019 Alexander saw his talk. Reviews asked for paper, the publisher demanded 160 pages, and 300 came out — "stone soup". Evans's book is both current and outdated: concentrated wisdom, but no event sourcing, CQRS, or domain events, and no second edition is coming. So Vlad's book is for the first belts, to bring them to blue; for black, read Evans.

On translation: an agreement with a Russian publisher is signed, but the plans are unknown. Vlad has lived in Israel since 1995, would not translate it himself, and has arranged it with people from the DDD Telegram community who live in that language. Alexander corrected the Kleppmann translation, where the meaning was lost in places, and praises the translation of Alex Petrov's Database Internals, done with the author. On "ubiquitous language" — the club argued about the translation at the first session, and Vlad uses the Russian word for "single": "omnipresent" suggests universality, while the language is single only within a context. To "has anyone seen healthy DDD" Vlad replies that at conferences he heard one thing: we have brownfield, we need management's permission, we are accumulating theory for now. In practice DDD is not black and white: you need neither a CEO with a corporate strategy nor a team quoting Evans; more often you meet disguised DDD, reached through leading questions — do we want the data to survive a server crash, so one transaction, so smaller boundaries for performance.

Vova picks up: for greenfield take the widest context and tighten as needed; Vlad agrees — a startup does not know what it will do in six months, and rushing into microservices with small contexts is a road to nowhere; safer boundaries make refactoring easier. Ilya recalls services sliced piece by piece until the budget ran out half a year later and they all lived on one node. Alexander describes the system design section of interviews: strong candidates see the problems of the happy path themselves, others need "what if" prompts — and a case where a technically strong developer cut ten services that were later glued into three so transactions would not jump across boundaries. Alexander adds an example with grades: a decision tree does not replace understanding why the decision is what it is. Evans, Vlad notes, has a chapter on the iterative approach that got lost among the rest of the wisdom; the WolfDesk example was added for the self-check questions the editors proposed to drop, and there is deliberately no compilable implementation — but readers asked, and the repository promises "soon".

Among online formats Vlad ran an O'Reilly training on DDD for monoliths — four iterations of six hours — and values live interaction, although the platform shows participants only by initials: "those are value objects, collisions all the time". On reference data that users edit in an admin panel: Vernon defines it as value objects, but two rows with the same status and different identifiers make no sense, while a string instead of a type prevents any later change, so Vlad models it as an entity for flexibility or introduces an upper-case machine code with a dictionary for humans. Modelling tools are Miro, a whiteboard, and paper; he used code generation once, for a domain with a huge number of events in C#, and today would treat it as a warning sign: the model is too complex and may hide several contexts. Changing an aggregate's identifier is the rarest exception, like a changed passport number; Ilya jokes about witness protection.

Reading another service's data through a purpose-built view instead of a trivial REST API: a foreign database is bad form, but if the view is built for integration and declared a contract that does not break when the internal model changes, Vlad sees no problem — it is a published language, and data mesh has a similar move. On saga versus process manager: he checked the terminology with Chris Richardson so everyone speaks the same language; the saga comes from an old typewritten paper, the process manager from Enterprise Integration Patterns, and they are almost the same: a saga is drawn as arrows between services, a process manager carries its own lifecycle and complex logic — "if a saga has an if, it is a process manager". The anti-corruption layer lives in the same lifecycle as its context or is split out when the source keeps breaking the integration. Vlad recalls integrating with a team whose core domain changed constantly and whose events did not always arrive: they were combined with a periodic full export through a separate API — Alexander recognises the lambda architecture. Transactionality across two databases means a distributed aggregate, and the right question is what level of transactionality is needed, not how to provide it.

On the future: writing was so hard that Vlad swore off even text messages, but the contract was signed for two books at once. The second — Balancing Coupling in Software Design — needs more research, is in draft under review, and, whatever Amazon says, will not come out in September. His recommendations: an old 1970s book on procedural programming that changed his understanding of microservices, and A Philosophy of Software Design, short and fundamental. The author's closing thought: do not treat DDD as an all-or-nothing prescription. He once wrote that he would drop the tactical part, the community came down on him, but the position stands: the core of DDD is the ubiquitous language and bounded contexts, while aggregates and value objects are a generic subdomain already described by Fowler. Vlad has seen projects with hundreds of aggregates and repositories that had nothing to do with DDD, and projects without a single aggregate but with contexts and a language — and those were real DDD.