"Our thoughts create our reality -- where we put our focus is the direction we tend to go.”
I have often stated that a tell-tale sign of a data-centric application design is designing the data storage first. Obviously database tables are not part of the problem domain, they are implementation details. Designing tables first means I am concerning myself with how I am going to implement something. I am no closer to action, action that solves a problem or even better, gets me closer to understanding the problem and its obstacles better. What I should be doing is learning what is involved in the problem and what is responsible for doing what, responsible for figuring out what.
So we shun the table design and focus on business objects because they are the whats, not the hows! However, here is where I often still make a mistake. I end up focusing on what the code will look like, the structure of it all, the objects I am sure are involved, the objects that will contain this and the objects that will contain that. In the end, this approach is not much better than the data-table-design-first approach as the focus is still on how things will be organized and implemented without any real concern with solving the problem.
Those in the test driven design/development (TDD) club (which I am not exactly a full blown member) realize this and propose a solution that requires we write tests first. This forces us to focus in on responsibility and let the need for certain things to get calculated and determined drive what objects will exist. After that happens we can then figure out how those objects will do their calculations and determinations, and we will figure out how those objects will be persisted.
The truth is that the first step is to understand the domain, or in the case of a new feature we need to understand a subset of the domain. Often experienced developers can envision what objects will be required to support something after they get a good understanding of it. In the common business application there is often a correlation between an object and a table so one can argue we “know” what tables will be needed. Often we are right, or it at least it feels like we have guessed right because we make it work with what we have already created anyway. We build ourselves an object model or data schema box without realizing it is keeping us from thinking outside the box.
So when we think it through and write something down before getting started, make sure you think through the responsibilities required of objects and choose objects from possible candidates in the domain. Figuring out what exactly is going to happen (not how) and who should do it (what object) is your priority, your focus. When every responsibility is accounted for, then you have something that solves a problem. A data table or an object with data does not handle a responsibility, they do not solve problems, they only support the effort.