Is it always a good idea to modularize a project architecture?

Question

Software design

Let me explain a little the essence of the issue.
There are a lot of "classics" about the organization of the MVC paradigm.
There is an HMVC paradigm (I first met it when I worked with CodeIgniter). The essence is approximately the same, only we select the modules within which we build the MVC model. It seems to me that this is a fairly well-known approach (and logical), but not everyone is familiar with this term (maybe there are others, not the point in this context).
On duty / work on the project, I encountered the difficulty of separating entities into separate modules. The project is a highly connected process. If we discard all the nuances, then this process can be called "document flow tied to various business processes."
The difficulty lies in the fact that it is very difficult to single out "variable" modules, or disable some module. In the current plot, the process will simply cease to be continuous and will come to naught. And accordingly, the system will cease to be viable.
A little research and the terror of friends gave very interesting food for thought: quite a lot of large projects implement the "architecture of services": a restriction is introduced on "communication" between different entities directly. The communication itself is organized through a service - a gateway and / or other similar tools (API / SOAP / JSON / XML). The concept of "status" of a message/process movement is also introduced. Depending on it, the "location" in the business process is determined.
"Variators" are introduced by partially duplicating the code. Addressing them is due to the introduction of additional statuses.
The flow of a business process can be determined by mapping (in case it is necessary to implement alternative ways of data movement. For example, under certain circumstances, we do not execute some part of the logic, but send a request to a third-party service, and then catch the answer and transfer to the third status).
I would be grateful for additional information about this approach, there may be pitfalls that should be considered, what to read on this subject (and how it is properly called :) )
Thanks in advance.

Answer 1

Well, it all depends on the specification. If the system is planned for further integration with other products, or is a boxed solution, then of course it can be made modular, with the ability to replace parts of the system with third-party components. If not, then you will spend precious time on developing, testing, debugging such a modular system, which you will no longer have enough to complete the project on time.

Answer 2

MVC is aimed at decoupling BI from UI to the maximum. Your task, as I understand it, is more complicated than the UI for data processing. Read DDD , pretty sure this is what you need.

Answer 3

Yes.
Confirmed by millions of years of evolution: lenta.ru/news/2012/07/16/modulenet/
Rendered into one of the fundamental principles of engineering: ru.wikipedia.org/wiki/Separation_of_responsibility

Answer 4

Write in a way that is convenient for you and then you will not be ashamed. This is the main approach :)

Answer 5

Since the project code has not seen anything, I can’t say for sure, but try to use more functions placed in separate libraries. Functions that are basic to bring interaction libraries. At the implementation stage, you only need to compile the necessary elements:
Elements:
The program is the base.
The base library is the base module that defines the interaction between elements.
Library "module1"
Library "module2"
Library "module3"
Library "module4"
Compiling:
Program
Basic library
Library "module2"
Library "module4"
And that's it. The system is easily expanded by adding modules. In general, this is a matter of taste, but I would write the system that way.