With all the good and bad that goes with it, I focus a lot on the design of the applications and application components I work on. This, in part, stems from my appreciation for both the art and science of software development, which is a topic I've been meaning to post about for some time. Since I put a strong emphasis on architecture and design and I'm usually supporting other people's projects, I tend see a lot of different design approaches. Most of these approaches have been centered around the database, which I think is inappropriate for most systems. What I mean by this is that the developers start with a relational database structure and design their domain objects and business services around that. This is typically done by developers who either don't have a lot of design experience or have a strong background in database development. While I admit that every approach has its pros and cons and every project has its priorities, I typically try to focus developers on the application first, whether or not a data store already exists. I've seen bad data structures drive the application's design too many times. I actually discussed this with a coworker a few days ago and we both agreed that most applications should focus on the domain model and core business services during design rather than developing them from a pre-existing data model. Jeremy Miller  talks about this in a recent post, Don't Let the Database Dictate your Object Model . I'm glad to see others professing this practice because I think it's very important and not enough people take it into consideration. All too often, database-driven application designs force unnecessary constraints on the system, limiting innovation, growth, and extensibility.