Hello, Miguel.
You state well the necessity of adopting these sorts of strategies to promote the long term viability of Koha. Without architectural clarity, the ability to add and refine features is growing increasingly difficult without stepping on other people's work and introducing action-at-a-distance bugs. Working toward a solution to this dilemma is exactly the purpose of having a technical committee^H^H^H^H^H^H^H meetings to hash these issues out and try to develop a consensus on which tools and patterns would best suit Koha, then draw a road map describing incremental steps developers can take in order to get from point A to point B.
I have a few high-level ideas toward this end:
* start separating out the monolithic C4 modules into Model and Controller modules, cleaning up circular dependencies as needed.
* move most of the contents of .pl files into the View modules.
* switch to more flexible template system, like TT.
* split out C4::Context into "user" context for authorization, "schema" context for data sources, "environment" context for CGI vs. CLI vs. PSGI
* centralize database access calls, either through an ORM or through a customized layer on top of DBI.
I think the specific tools applied are less critical than the underlying principles which any number of those tools could facilitate.
Cheers,
Clay