Funny you mention monolithic code. The post expressed a very important thought:<p>&gt; we’re trying keep the parts that change frequently, away from the parts that are relatively static<p>Modularization and good code contracts help &quot;sequester&quot; code parts with different rates of change.<p>And this is my guiding hunch when I am splitting up code and deciding on module surfaces: <i>how confident are we in the subject matter</i> that given code describes? This does not replace actual proper concept modeling, but it is an intuitive feel for helping future iterations go smoothly.