[cbetti]

Patterns and automation supporting modularization hasn't received the attention that patterns and automation around services has over the past 10 years.

In practice, modularization raises uncomfortable questions about ownership which means many critical modules become somewhat abandoned and easily turn into Frankensteins. Can you really change the spec of that module without impacting the unknown use cases it supports? Tooling is not in a position to help you answer that question without high discipline across the team, and we all know what happens if we raise the question on Slack: crickets.

Because services offer clear ownership boundaries and effective tooling across SDLC, even though the overheads of maintenance are higher versus modules, the questions are easier and teams can move forward with their work with fewer stakeholders involved.

[muxator]

If a dev team cannot self-discipline itself in maintaining a module, is it wise to entrust it with the responsibility of a whole service?

I'd rather work on better mentoring the single members.

[watwut]

Modules have higher requirements for self discipline the services. Precisely because the boundaries are so much easier to cross.

And also because it is harder to guard module from changes made by other teams. Both technically and politically, the service is more likely to be done by a single team who understands it. Module is more likely to be modified by many people from multiple teams who are just guessing what it does.