How to understand your problem domain

Before you can start with programming you have to know what application you want to build. It is possible that this is done for you by others and you just get a detailled specification of what you have to implement. On the other hand it is also possible that you are the one who has to specify what application to build, either together with a client, if it is a client project, or alone/with your team if it is a product/internal project. Of course, there isn’t just one way of doing it. So the following is just one possible way.

Let us imagine we want to build a simple blog application (highly imaginative, I know *g*). But what does that mean? As there is no client we can ask, we have to imagine how the application will be used:

“The user logs into the application and writes a blog post. When he finishes the post, he adds tags to the post to categorize it. Then he publishes the post.”
“The (web) surfer reads the post. and because he wants to add additional information, he writes a comment.”

As it is a simple blog application, that is everything that can be done with it ;-)

From these requirements we can extract the core objects of our application, which are:

• User
• Post
• Tag
• Comment

Those objects usually have associations among each other, which we can visualize in a domain model (I recommend to use pen and paper to draw the domain model as you will be much faster than using a software tool):

With the domain model we have an image of the part of the real world that is relevant to our application (the problem domain). Things like foreign keys, id attributes, methods, and other details are not relevant at this level.

The next step is to develop the design based on the domain model. In the CakePHP world this usually means the creation of the database design. But that is outside the scope of this article, and left as an exercise for you ;-)