Domain-Driven Design and Requirements Survey

Question

When we use Domain-Driven Design an important part of the development process is to contact business experts to have a good understanding of the domain in question. This can be done, for example, with interviews with domain experts and for what I know the main goal is to understand the domain itself at this time, the rules and business logic and build a ubiquitous language.

Another main point to develop a software is to know its requirements, especially the functional ones. This can also be done with interviews, seeking to know what the system should actually do and then writing user reports and use cases to detail the requirements.

Besides, from what I know, both processes are usually iterative. Throughout the development we try to understand more and more the domain and review the knowledge we already had and also throughout the development we try to better understand the requirements.

These two processes seem to me different things. In the first the objective is to understand the domain and in the second understand what the software should do. But I doubt how to reconcile these two processes.

What I mean by that is, what should we do first? Should we first try to get to know a little bit about the domain and then start collecting the requirements or should we first try to understand the requirements and then get to know the domain? Or somehow these two processes are performed simultaneously?

In summary, how to efficiently reconcile the process of collecting requirements and understanding the domain?

Answer 1

Interesting you see understanding of the domain and requirements as two distinct processes. I’ve never seen it this way. For me, knowledge of domain comes during the lifting of requirements.

But I’m using "requirements survey" here in a very broad sense and I don’t know if we’re aligned, so allow me to go a little bit deeper.

What the customer knows

The customer never knows in advance what exactly he needs in terms of software, but he always knows what he needs in terms of business and he has some idea where a software fits the solution of the problem.

So the customer comes to us with a need of the kind:

"The machine that fills these containers should know on its own how much material to put in each one, because today this is controlled by an employee and it is difficult to hit the exact amount."

Steps in the lifting of requirements

What I understand by requirements survey starts here.

Desired capacity

What the client knows he needs we can call "capacity".

The client has just told us the new capability he wants to have on his system. See how the need can be rewritten using this word:

"The machine that fills these containers must have the capacity to match the exact amount of material to be placed on each without being dependent on the intervention of the official."

Understanding of dominance

Now, to figure out how to make software that delivers the desired capability, we need to understand the domain.

The process of understanding the domain is a work done in order to discover the software requirements, and is limited to meet this function.

This means that the software team is not interested in knowing the client’s entire operation; then the software team will not spend days in meetings with the business experts to become as expert as they.

Instead, the team will look to the experts how the employee decides the amount of material in each container; so as to understand what entries are available for the new software.

The team will also seek to learn how the employee operates the machine when they decide to interrupt the work of filling a container; so as to understand which outputs the new software should produce.

At first, the team is not interested in anything other than the operation of that particular machine, and it will only extend its learning to other details of the customer’s operation if this proves necessary during this effort to understand the machine. In principle, the domain problem is just machine operation.

So we can conclude that domain is area of knowledge of the problem that the software intends to solve. Domain is not the knowledge of the entire operation of the client.

While learning about the machine, the team begins to exercise the ubiquitous language. The language begins to be elaborated during the work of drawing the first requirements.

Software requirements

A software requirement is one of the features that software should offer. The set of all software requirements must deliver the desired capability.

In DDD, it is impossible to formulate a software requirement without the ubiquitous language. But the construction of ubiquitous language is not a separate process.

The construction of ubiquitous language occurs during the effort to formulate the software requirements.

Completion

• The purpose of the software project is to deliver a capacity (possibly more than one).

• Domain is the area of knowledge of the capabilities that must be delivered by the software.

• To ubiquitous language is built during the effort to formulate the software requirements, it is enhanced during the elaboration of each requirement, and the elaboration of the requirements takes place throughout the project.

• Software requirement is one of the features that software should offer.

• The ensemble of all software requirements should deliver the desired capability.

• The learning of the domain and the consequent construction of the ubiquitous language happens subject to the lifting of requirements, during the lifting of requirements, and is delimited by the desired capacity.

We can say that knowledge of the domain and the resulting construction of the ubiquitous language are "pulled"* by the need to raise requirements.

_{*See push system or pulled system, that in short is "do what is necessary only when necessary and only in the required amount".}

Answer 2

I believe that a good way to reconcile both definitions (Domain and Business Rules) or the use of DDD practices with BDD (Specification By Example). As we can see in the image below, they act on the same concepts, but with different approaches:

Considering this, and using language Gherkin, we can define a business requirement defined as follows:

Cenario: Comer 5 de 12
  Dado que existam 12 pepinos
  Quando eu comer 5 pepinos
  Então devem existir 7 pepinos

So now you have a requirement, which uses domain objects to be valid, you have been explained about an example of how it should work, now you must define well each related object.