What do you model and when? (Enterprise, Application and Database Design Modeling)

Imagine that you are designing a web application that could possibly grow to the scale of Amazon or Google. In the beginning you start with only one small aspect of the project knowing that, in the name of agile development, you have to start somewhere. For example, you might choose to create a simple directory of books hoping that your project takes off and some day you'll be not just a directory but a one-stop site for buying and selling books as well as all kinds of other merchandise. (This is all purely hypothetical.)

What are the different types of modeling you would employ? What are the different "entities" that you would model in the beginning? How important do you think modeling is and wha开发者_C百科t information should you use to determine when and what to model?

In an answer on a previously asked question on SO there is reference made to the "data centric world view" versus the "process centric world view". Do you model the flow of information across an application or website(s) before you start to perform logical data modeling and physical data modeling? Or do these phrases refer to something different?

What tools might you use for modeling the different types of information?

---

My modeling is usually done on a piece of paper or sometimes a whiteboard. I came a long way from writing exhaustive technical designs, but I found out that it is no use at all to think ahead to features you'd like to have in a few years or even a few months. Your requirement will change continuously, so you should program for the 'now'.

That is, when it comes to modeling.

Of course you should think of what what happen if your company grows, but not in features, only in performance. Would your app still run if you got 10 times the visitors, 10 times the products, 10 times the orders... Those things you need to worry about, not about what you are intending to build in 2 years. There's no way you can foresee everything, and all attempts to write 'smart' and 'extendable' code, will result in a more complex system that is even harder to customize in two years than it would have been if you didn't think about it at all.

Just build what you need now, and build it lean and clean so it can be extended, refactored or replaced in the future.

---

The future proofing of models is different from the future proofing of implementations.

Here are some models I have used.

Data models:
    Analysis model (conceptual):  Entity-Relationship modeling
    Design model (logical):  Relational Data Model
    Implementation model (physical):  DBMS specific model

Application models:
    Object Model:  governs messaging among component objects.
    Dynamic Model:  governs states, events, and transitions within an object.
    Functional Model:  governs transformations and computations.

Models are important for what they leave out, as well as for what they leave in. Don't try to anticipate everything, but don't paint yourself into a corner either. Learn from the experience of others, then learn from your own experience.

---

In my experience, starting with proper, highly normalized Db design is a key to extensibility down the road. The more atomic you can make your Entities, the more easily extensible your system will be when the unknown "future Needs" crop up. There is a difference between planning ahead for something you KNOW you will be adding, but cannot for the moment due to time constraints, or possibly (JUST possibly) hardware limitations of known duration. But that is different than planning for "What if we become Google II".

On the back-end, a strong, highly normallized table structure. On the front side, clean, loosely coupled classes and an n-Tier design go a long ways towards extensibility.