We found that business logic is such an important aspect of an application that it deserves a special place in the Model View Controller architecture.
The Model View Controller architecture is the de facto standard for web applications. As an application framework grows, the structure of the model becomes more and more important. The model is responsible for storing business objects in a persistent store, but it also deals with all the business logic of an application. And it is exactly these two responsibilities that we want to separate.
As described in the previous parts of this series, our modules use API's, an API Factory, and repositories. These would all be part of the model in the MVC architecture.
We consider just the repositories to be part of the traditional model. We place these in the model directory. We reserve a special directory for the business logic of the module: "logic". This directory contains the API's and the business logic classes they use. The logic directory contains just business rules and object definitions. It has no hard dependencies on anything that may be replaced when a different implementation is needed. Special case in point: no database code can be found in the logic directory.
If one wants to separate the logic code from the non-logic code, it is important to understand what exactly is meant by business logic. So here is a definition:
Business logic consists of those functions that are essential to the use cases / services of the application.
Note that the definition uses the word "functions", because this code serves as a library, a toolset, not just to the module itself, but to other modules as well. What goes on inside those functions is irrelevant to the user, it is the input and output that matters.
Note also the word "essential". I use it to distinguish business logic from its dependencies. For example, when a function needs to store its data, it might not be important where the data is stored exactly, as long as it is stored safely, and can be retrieved. The fact that MySQL is used is irrelevant to the business logic. MySQL is just a dependency. And that is the reason that it is best injected in the API from outside. That way, MySQL can later be replaced by another database, or a test mock object.
Photo: Friends, they are beautiful