A modular monolith can be more flexible than a tightly woven set of tiny services. A dogmatic extreme following of either approach will lead to pain.
Context matters, early in a project a modularly build monolith can lend to rapid development. The current standard leads to having to commit to three or four separate repos with all the associated merge requests builds and hoopla involved. Not to mention the SG and DA processes involved in some changes. (The repos: DAO -> BS -> BFF -> UI). Then if things are split into small services this multiplies by the number of services involved.
For an early stage project put it all in one repo. Then when things have been given time to form and service boundaries can be drawn with the benefit of some experience split it as needed. A "monolith" can and should be as modular as a well factored set of services and this approach removes some of the incidental complexity that hampers progress at the beginning of a project.
Is there documentation on the <company> theory of services, when and how to split? Is it easily discoverable?
What does Service Oriented Architecture mean here? Does it mean an architecture build of a bunch of tiny services glued together with some swagger and http? Or does it mean systems which map and correlate with the business domains which they serve? Who and where is this discussed?
One thing I am not sure of is how the standards come to be and what flexibility is built in for alternate ideas on the surface it seems that things are quite inflexible and rigid. I like to think I just have not discovered how change comes to be.
Vernon Vaughn and Tomasz Jaskula have written an interesting book on this subject, it isn't long and I think definitely something to think about: Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture
Vaughn wrote the "Red Book" on DDD: "Implementing Domain Driven Design" which seems well respected and I like it https://learning.oreilly.
Vaughn also wrote "Domain Driven Design Distilled" which is a lot shorter, easier to digest and makes a good intro to the red and blue books: https://learning.
The Monolith/Microservice book pairs quite nicely with Dave Farley's book: "Modern Software Engineering" which promotes and encourages an iterative approach with predictions and feedback. It explains how engineering fits into software and presents an approach that makes a lot of senes. It is not a long book take a peek on O'Reilly online learning: https://www.oreilly.
