Building Maintainable PHP Applications: Planning
This article is part of the Building Maintainable PHP Applications series
Many developers focus mostly on the technical planning first before they understand what needs to be done, and sometimes they are even building the wrong features that the business needs.
Technical planning is important but I would say that understanding the business processes first and planning the use cases of what needs to happen is more important than that.
In most cases, the use case planning is almost non-existent.
Sure, there are user stories but they don’t represent the whole picture of the process.
There may be many ways of planning business processes but I would mention:
Event Storming
Event Modelling
Event Storytelling
They are somewhat different in how they work but they have similarities that focus on the events that happen in the product from a behaviour point of view.
The idea of these planning processes is for customers, business people and technical people to get into a room, and discover what and how the business processes will work in order for the technical people to build them.
Here’s an example of how an Event Storming board looks like after a few hours or sessions of event storming:
The good thing is that you can look at the board and quickly understand how the system works, what are its capabilities and you don’t really have to guess what’s happening just by looking at the code.
If you manage to solve the problems before you write a line of code, you will have an easier time writing the code, because you already figured out pieces of how the processes work with the current knowledge you have.
It’s not possible to know everything at the beginning but at least it will give you an idea what you need to do and what needs to be covered when the software gets built with technical tools and code.
This type of planning can also help you figure out the modules (bounded contexts) in your monolithic application, which will also help you with the folder structure, if you prefer to structure it out by feature rather than by type.
Another example of how a board at the beginning looks like in an event storming session with the modules (bounded contexts) figured out:
And here how these modules would look like in the project:
As you explore the domain and it evolves, you figure out your modules and business rules.
At some point, if the product evolves to the point where teams need to be split to work on multiple applications, you could easily move out each module out the monolithic application.
The goal here is not to expect or chase the complexity but rather let it evolve and manage it.
Once you know what you are building, it’s easier to just build it with the chosen tools, technologies and figure out the implementation details.