When three client departments mean three things by "order"

Picture your first week at a logistics company. You have been asked to build an agent that answers the question “how many orders do we have today?”. Sales says 420, the warehouse says 380, accounting says 350, and none of them is wrong.

To sales, an “order” is a quote the customer has signed. To the warehouse, it is a pick list. To accounting, it is an issued invoice. The three numbers are hypothetical, but the situation is common: one word, three models, and your code will be wrong if it picks the wrong one.

Vaughn Vernon’s Domain-Driven Design Distilled tackles exactly that problem in under 200 pages. If your job is to sit with a client’s domain experts and turn the way they talk into a working system, read this before the thicker books.

A slim book, written for non-coders too

The book was published by Addison-Wesley Professional on 23 May 2016, first edition. The print edition runs to 176 pages, ISBN-13 978-0-13-443442-1. Vernon draws on roughly twenty years of applying DDD to real-world situations. The publisher’s description stresses that it is concise, readable and actionable, and does not bury the reader in detail.

The intended readership is worth noting. Pearson states that the book is for programmers, architects, analysts, consultants, and customers too. For an FDE this is immediately useful: you can hand a single chapter to the client’s head of operations so that both sides use the same vocabulary in meetings.

The table of contents has 7 chapters, opening with “DDD for Me” and closing with “Acceleration and Management Tools”. In between come subdomains, context mapping, aggregates and domain events.

First idea: the shared language must be built with the client

Chapter 2, “Strategic Design with Bounded Contexts and the Ubiquitous Language”, is the most important part of the book for FDEs. The book’s description says the ubiquitous language is developed within a clearly defined bounded context. The book guides domain experts and developers in creating that language together.

“Together” is the key word. A glossary you write on your own after a meeting is only your own translation. A glossary the warehouse staff have edited line by line is a shared language. Back to the logistics example: when someone from the warehouse crosses out “order” and writes “pick list”, you have just found a boundary.

The first thing to do at a client: in every discovery session, write down every business noun. Then ask who uses this word, and at which step of the process it begins and ends.

Second idea: split the models, don’t merge them at all costs

Many engineers’ reflex is to create a single orders table for the whole company. The book runs against that reflex. It teaches how to separate domain models with the Bounded Context pattern, so that each model holds true only within its own boundary.

Applied to the agent above, the right answer is not one number but three: signed orders in the Sales context, pick lists in the Warehouse context, invoices in the Accounting context.

The agent should ask which context the user means, or choose the context from their role. That single design decision is enough to avoid a week of arguments about “wrong numbers”.

Third idea: draw the map before writing the integration

Once there are several contexts, the next question is how they exchange information. Chapters 3 and 4, on subdomains and context mapping, help directly with drawing the client’s business boundaries. For an FDE, the context map is the integration design: how a pick list is created from a signed order, and where an invoice gets its data.

The final chapter introduces acceleration tools, including event storming. You can run it in a workshop with the client to surface business events and boundaries, rather than guessing them from the database schema.

What are the two easiest mistakes to make?

The first is writing the glossary alone and sending it to the client to “approve”. Busy people tend to nod it through, so the places where one word carries two meanings stay hidden until the agent gives a wrong answer. The fix is to have the client correct the definitions during the meeting itself, as the warehouse staff did when they crossed out “order”.

The second is inferring the model from the database schema. If there is only one shared orders table, the schema hides the fact that three departments understand it three different ways. Treat the schema as something to check after you have listened to the users, not as the starting point.

In what order should you read it?

If you are about to start a new engagement, read chapters 1 and 2 first, because they are useful from the very first meeting. Move on to chapters 3 and 4 when you start designing the integration, then read the final chapter when you need to run a workshop.

The chapters on aggregates and domain events can wait until you are actually writing core code. That is the tactical part: useful, but not urgent for someone still learning the business.

How do you make this skill visible to employers?

When reading FDE job descriptions, look for requirements about domain modelling, turning business requirements into systems, or working directly with client stakeholders. Those are the places where skills from this book deserve a mention.

On your CV, don’t write “knows DDD”. Write something verifiable, such as: “worked with the client’s operations team to identify three bounded contexts, agreed a definition of an order, and eliminated data discrepancies between the warehouse and accounting”. In interviews, tell the story of one specific time you found a word with two meanings.

Badly written integration code can be rewritten. A boundary drawn wrong in the first week will follow you for the whole project.