Not all knowledge is equally useful when building a software system. Knowing about writing Java code in the financial domain might not be very beneficial when you start creating an iOS app for real state management. Of course, principles like Clean Code, DRY and so on are helpful no matter what programming language you use. But the business knowledge of one domain might be vastly different from what you need for some other domain.

This is where we encounter the concept of domain knowledge. Domain knowledge is obviously the knowledge about the domain where you are going to operate with your software. If you are building a trading system - your domain is financial trading and you definitely need to gain some knowledge about trading in order to understand what your users are talking about and what they really want.

This all comes to getting into the problem space. If you are not able to at least understand the terminology of the problem space; it would be hard if not impossible even to speak to your future users. If you lack the domain knowledge, the only source of information for you would be the specification. When you do have at least some domain knowledge - conversations with your users become more fruitful since you begin to understand what people are talking about. One of the consequences of that would be building trust between a customer and a developer. Such trust is hard to overestimate. A trusted person gets more insight and mistakes are forgiven easier. By speaking the domain language to domain experts (your users and customers), you also gain credibility and they see you and your colleagues as more competent people.

Obtaining the domain knowledge is not an easy task. People specialize in their domains for years and decades, they become experts in their domains and they do this kind of work for a living. Software developers and business analysts do something else and that particular problem domain might be little known or completely unknown at the moment they start to obtain the domain knowledge.

The key part in obtaining the domain knowledge is effective collaboration. Domain experts are the source of ultimate truth, at least we want to treat them like this. However, they might not be. Some organizations have this knowledge fragmented, some might have it just wrong. Knowledge crunching in such environments is even harder, but there might be bits and pieces of information, waiting to be found at desks of some low-level clerks and your task would be to find it.

The general advice here is to talk to people and talk to many different people, from inside the domain, from the management of the whole organization and from adjacent domains. There are several techniques to obtain the domain knowledge and here are some of them:

• Conversations are the most popular method, formalized as meetings. However, conversations often turn into a mess without any visible outcome. Still, some value is there but you need to listen carefully and ask many questions in order to get valuable information.
• Observation is a very powerful technique, which heavily correlates with the Lean Startup motto Get out of the building. Software people need to fight their introversion, leave the ivory tower and go to a trading floor, to a warehouse, to a hotel, to a place where business actually runs, and then talk to people and see how they work. Jeff Patton gave many good examples in his talk at DDD Exchange 2017 (https://skillsmatter.com/skillscasts/10127-empathy-driven-design).
• Domain Story-Telling, a technique proposed by Stefan Hofer and his colleagues from Hamburg University (http://domainstorytelling.org/) advocates using pictograms, arrows and a little bit of text, plus numbering actions sequentially, to describe different interactions inside the domain. The technique is easy to use and normally there is not much to explain to people participating in such a workshop before they start using it to deliver the knowledge.
• EventStorming, an extremely useful technique, which is invented and coined by Alberto Brandolini. He explains the method in his book Introducing EventStorming (2017, Leanpub) and we will also go into more details later in this book when we start analyzing our sample domain. EventStorming uses post-it notes and a paper roll to model all kinds of activities in a very simple fashion. Workshop participants write facts of the past (events) on post-its and put them on the wall, trying to make a timeline. It allows discovering activities, workflows, business process and so on. Very often it also uncovers ambiguities, assumptions, implicit terminology, confusion and sometimes conflicts and anger. In short everything, what the domain knowledge consists of.