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?

In general, before developing a software should be a great process of analysis. Documentation, client interviews, the client must appoint someone to be supportive of the analyst, someone who will know the team that will develop.

Many companies hire someone who does Business Analysis, that guy often takes all customer issues and interacts with the development team, passing needs, evaluating implementation, taking questions. The work of those professionals is limited to be the guy better informed about the project, he knows how to deal with the lay client and the developer is highly technical.

The Architecture team, the problems must be understood to design the way the software will be developed, which solves that problem solutions, and even find parts of the implementation that can be shown, working on a solution that will make implementation feasible.

But I work alone, how can I use this?


When working alone as a freelancer, is even more important to use this type of technique, since they waste time developing something useless, we lost money. In our area our projects take time. This generates profit in the long term. Of course we receive an advance, we can settle payments in stages of the project, but even so any changes can delay and delay will profit.

So you have to be the analyst will have to understand the customer’s problem, interview him, document, and generate reports of the problem and the solutions for the customer to read and can tell you whether or not this is the right view .

Create wireframes and deliver to the client to validate, is a great solution, create a presentation with all the software works and present to you client on a screen, in addition to professionalize their work, will get all your questions and the client about the project.

Include it in your costs and deadlines.

If you adopt these patterns, their work flow.

For a development team is essential, even if not a Business Analyst, elect someone in their client to be who will answer your questions, take them all before you start to develop, and in case of error, make a solution and not try to adapt a solution, refectoring the aplication to solve that problem. Use software design patterns, this facilitate these changes when necessary.

And remember. Even doing all this will change in time of approval. But no changes will not have understood the problem.

Find more about Domain-Driven Design.

by Paulo Teixeira

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.