The models created during the design phase aren’t just for managers and stakeholders. They are needed for creating quality code. If you (as the developer) take the model and translate it into a 500-line procedure with dozens of GoTos, you’ve really missed the opportunity to leverage all of the assets gained during the design phase.
Models are naturally bounded. In fact, the word model ultimately derives from the Latin word modus, which can mean bound or limit. Coding from a model is like drawing a circle in the sand and claiming that everything within the circle is the entirety of a functional and well-designed system. This claim leads to another software word derived from the Latin modus: module.
- Testability: Most modern day developers see automated testing as a cumbersome task with output constantly in a fragile state. For example, if a developer wants to test validation logic of a web application, he or she is often required to either manually click through a web page or write an automated script to do the same thing. By breaking data validation from presentation logic, we can now test that a value is an email address, independently from testing the text input from where that email address came. Consider a validation library like formance.js. Tests could be run against that library without ever knowing or seeing the actual page HTML.
- Code Isolation: Every developer has, at one point or another, been burned by what the industry considers “spaghetti code”. You follow one global variable to another, make a minor change, and suddenly see regression in a completely unrelated component of the application. Modularity solves this issue by promoting less (or no) global state and clear communication mechanisms between modules.
It has been made clear throughout this series that modeling provides us with the opportunity to view situations from multiple angles. And through this new lens, we can see better how models allow business analysts, IT managers and developers alike to assist in creating better applications.