Ideal Application Structure

Before getting into how to write test code we should discuss a few things in advance. One of these things is what the structure of an application ideally looks like.

Although the picture above looks more like a Lego brick than an application, it does give a good idea of what the ideal structure looks like.

Let's start by imagining that the blue cube you see is the actual application. This is the code in the repository that we clone when we want to set up a project.

As you might of noticed, there are also some green blocks on top of the blue cube (our application). These green blocks are in fact modules. As in the same modules that composer manages for us.

Modules

So what are these modules? What is their purpose?

Well the answer to those questions could be anything. It really depends on the module. In the image below we show some examples:

In this example you can see that we have a "third party" module. That could be a module containing some functionality that we need for our application, maybe to interact with the twitter API for example.

We also have a module named Laravel framework. As you can imagine that module contains the code of the Laravel framework.

There is also a module named "Business logic". That is an interesting module, because it contains the code that is specific for our application. (https://en.wikipedia.org/wiki/Business_logic) The reasons, that we should place our business logic in a separate module, can vary. An important point to consider is that we would be able to implement our application on any framework, not just the one that we chose initially. Also imagine that we would have to build a different application that also needs that business logic. By separating the code we can re-use it.

So what exactly can be considered business logic and what cannot? This is kind of a grey area, but it would be safe to say that in most cases simple CRUD actions are not business logic. Most of that code is nothing more than (based on MVC) having the controller accept the request, using a model to manipulate or read the data and using a view to present the result to the user. Basically features that the framework provides.

Now let's say that we have an application that can calculate how many rolls of wallpaper a person needs to decorate a wall of a dimension specified by the user. Of course the application is able to do many other things, but the specific code to calculate the number of rolls can certainly be considered business logic.

We can use that logic to create a function for a web shop that sells wallpaper. When the logic is separated into its own module we can also use it when we need to build a site that specializes in giving advise on home decoration.

Conclusion

We should separate our business logic into modules. That way the logic can be re-used. Also if done correctly the business logic can be implemented in different frameworks or on different platforms.