Enterprise Rails

Refactor from Day One

Our final data model, with addresses factored into their own inherited table, and with ratings, payment types, and zip codes moved into domain tables, is shown in Figure 7-1.

Figure 7-1. Our data model after creating domain tables for zip codes and payment types

In terms of understandability, design elegance, and therefore maintainability, this is a much better design than we had at the beginning of this chapter. We haven’t created any controllers or views yet, but that’s OK—they are consumers of our models, and making changes to models becomes infinitely more difficult once active code is relying on them.

The real goal is to be able to spot opportunities for refactoring before design choices become entrenched in client code and before the design becomes problematic due to scale or lack of understandability, which leads to bugs. We are taking an intentionally slow and measured approach to data modeling here to point out patterns of refactoring that you should learn to spot in your own projects. Of course, we could have started with the “right” data model, but then the patterns of how to move from wrong to right would not have emerged.

Are there other opportunities for refactorings that may save us headaches down the road?

One possibility might be the credit card information stored in the orders table. Although it’s not likely to repeat in another table, the binding ...