How to get the necessary knowledge about a domain?

Question

In ddd one of the main concerns we need to have is to really understand the domain being considered, ie understand the business rules, processes and etc. Along with this is the construction of a ubiquitous language used by both developer and business experts.

Of course, this knowledge that we need to have about the domain should come from domain experts, but how do we get this knowledge efficiently? I mean, what are good strategies to get the necessary data from the domain experts?

Clearly, I am already assuming a scenario in which there is someone available who agrees to cooperate with development. I believe that the main way to get this knowledge is with interviews, but to come to the domain specialist and talk : "how does your work work?" seems to me a very broad question, prone to allowing loss of focus and with chances of not providing the really necessary knowledge.

So what are efficient ways to get the really necessary information from business experts and how to know what information is really needed?

Answer 1

Your question is more related to the survey and analysis of requirements than to the DDD itself.

The DDD does not provide any technique for lifting requirements. It makes clear that knowledge about the domain is deepened throughout the project, but how to do?

One way to do this is by using Agile methods:

Software demand always customer part

One important thing the question seems to ignore is that the demand for software at all times part of a client. At all times, siempre, Always, were to review, toujours, sempiternum!

But don’t worry, your question is not the only one to ignore this and this is one of the causes of the failure of software projects: try to meet demands that are not exclusively the real demands of the customer.

At this point you can begin to question:

• "Apple, with its recognized software, has a philosophy that the customer doesn’t know what he wants until you tell him".

• "Google introduced a ranking-based search engine that no one knew needed."

• "The owner of my company is a visionary, we develop the ideas in his head and then sell to customers who never demanded it from us."

• "I myself am developing a software that is my idea, no client asked."

But notice that in all these cases actually there’s a customer. The demands are coming out of the head of someone who knows what they want. Each microeffort should only be applied to software development if it is directly related to these customer demands.

Agile methods like XP and Scrum bring the customer into the team and the customer is not just there to answer questions or because they "agreed to cooperate" - the client assigned to the project is a business expert and is there to say what and when it should be done.

It meets one demand at a time, and each demand is very small

Thus, the knowledge of a small part of the domain is deepened at a time.

The client does not decide at once what to do and in what order to do, he does this work throughout the project because his own knowledge deepens as the software resources are being delivered.

Now, if you’re working on a specific demand, you don’t have to ask the client "how your work works" in the hope that he can explain it to you and you can take the whole domain in. Instead, you will ask, "how is this particular task accomplished?" and then developer and client will design a small software resource needed to meet a small demand.

How to transform the demand for an entire product into small demands

The step-by-step (very easy to understand and very difficult to learn to do) is:

• We start from a vision of the project or the software and also a vision of the domain - this will produce 1 to 3 small documents. The domain view is provided for in the DDD ("Domain Vision Statement").

• Great requirements are born from this view. A cool name for a great requirement is epic.

• The greatest value epic for the customer is chosen to be developed first.

• This first epic is divided into small requirements. A cool name for these small requirements is user stories. A cool template for user history is: me, in the role of X, want to do Y in order to have the result Z.

• Eventually a user story resulting from the epic’s split is still too big, so it will also be treated as epic and will be split again.

• When there are some small enough user stories, they are prioritized.

• Now, for each of the most priority stories, is that you ask the customer: how this particular task is accomplished? Hence paper prototypes can be produced (Mockups) and other documents, which are attached to the history.

After the visions are established, the rest of the process is repeated throughout the project.

Completion

In DDD, the macro knowledge of the domain is assimilated at the beginning of the project through the definition of the vision.

In the Agile Development of Software, this knowledge is gradually deepened throughout the project. Each small requirement will require the deepening of a small part of the domain, and the study of one part at a time is neither broad nor vague and is less subject to loss of focus.

The DDD, despite not providing techniques for deepening knowledge in the field, it makes it quite clear that this knowledge evolves throughout the project. The agile methods bring these techniques that are required by the DDD.