Is modeling a database model a good approach for designing complex and large enterprise application?
We're working on a freaky big service-oriented multilayered application, that has to be designed from scratch. Now we need to start programming, and try to assemble the first bricks.
The question is where to start? Some are suggesting that we should start by designing the persistent data models, which would provide a clearer view. Is this a good approach?
Edit for Suirtimed
There is not much an Agile culture here. This is an SOA style project, using WCF, SQL Server, Entity Framework (using POCO generator for Domain Objects), ASP MVC and Workflow Foundation. We are a team composed of 4 developpers; reasonably skilled (but not experts).
The broad overall approach I always try to follow is to begin by designing the domain models. This is your "ubiquitous language" which will define business objects and concepts, contain business logic (later on, when you have it), and generally be the common language used throughout the various parts of the system.
The idea is that it should be understood (or at least understandable) by everyone involved. For example, some manager in some other department isn't necessarily going to understand relational databases or anything about persisting his department's data therein. But he does understand the business process of his department. Their vernacular, their concepts, their interactions, etc. The ubiquitous language is the common ground the groups share.
During this process, you should keep your dependencies in the front of your mind. The biggest one is usually data persistence. There's sort of a golden dream that domain models be persistence-ignorant or dependency-ignorant in general, and for the purpose of separation of concerns that's a good thing. However, true dependency ignorance can paint you into a corner. You may run into some serious performance issues or architectural issues that require a lot of re-design later on.
So break from the domain modeling occasionally to think about persistence (and other external dependencies, such as external services that need to be used or third party applications that need to be integrated). As you model the domain, make sure that model still works properly with everything it needs to. You may have to compromise a little on the ubiquitous language here and there in order to accommodate the limitations of a dependency.
Basically, design the domain model before you design the database. But don't forget about the database during that process.
Since the database will be the key element that joins the enterprise application together, yes it is a good idea to start with it first or at least do it simlutaneously with the application designs. Do not rely on the application for how the database should be structured. You need to design for data integrity,performancem and security not object orientation! Start with a database design that is at least inthe 3rd Normal form.
Design of the data model is critical to performance and data integrity. And it is the more difficult thing to redesign later. Further, for an Enterprise product you will want some things that are only in the database such as record auditing which should be designed from the start. Likely you will want to know who made changes to records, what the change was and what application it came from. This will help tremendously in rolling back bad data changes and identifying what application caused a problem that created bad changes.
If you are designing completely from scratch, then yes, you have the advantage of defining how your data will look.
All I can say is, from my experience, it is helpful to get as much of the data structure / business logic designed up front as possible.
The deeper you get into your application the more difficult it will be to rejigger everything if the data has to change - and the data will change no matter how much you prepare, you just need to minimize these changes up front.
I personally would say, yes, get as much of the data design out of the way as possible. You can't put the cart before the horse.
We usually get started with some use cases to initialize some of the used entities for storing data. After that we are trying to do some database modeling and looking especially for the relationship between the entities.
If the base db model exists we will developing a prototype and trying to include as much use cases as possible in the prototype.