When we develop a software, we know that this software is to fulfill a need for someone. This need for those who requested the software can be characterized as a problem. Thus we conclude that a software used to solve a problem. All around the needs of the problem may be called the Domain.
Thus, the name Domain-Drive Design could be translated to: Lead the Design Application by Domain or maybe: Oriented Domain Programming (Problems).
This concept involves much more information that’s code is a pattern more conceptual than practical.
What we see in our work-days, is software development guided to anything, less then domain.
Is it common for you to develop an entire software and at the time the client approved, he asks a lot of changes?
When the changes are things that do not exist… It’s ok, but when the changes are like: “This field had to be plain text but comboBox.” You realize that the process failed. Or when the client says: “This financial processing module is wrong, the values do not match.” Well, now you have a problem again.
This type of situation can be avoided if we orient the development of our software for Domain.
But, how to guide the development for Domain?