I don't know about front to back, a good module should be explicit on what it affects and _ideally_ abstract its implementation. We were talking about what a module should aim to be, and that aim is a good proxy for a lot of properties of well architected applications, even when not perfected. And even when you don't plan to ever throw the module out.