How can i start with the class design before starting the development of a large application (both WinForm and WebApp). What are the initial 'be-careful' things i should check before designing the class structures?
How to identify the usage of interfaces, abstract classes, delegates, events etc in my application design?
A thorough answer to this question would require a book, not a StackOverflow post! In fact, there are quite a few books about this already, like Martin Fowler's Patterns of Enterprise Application Architecture. Here are some general pointers:
Make sure you understand the portion of the problem domain that you're working on. Have you talked to your customers to run things by them first? Does your domain model match the way they think about the world?
Statistically speaking, your application is unlikely to be special. That means that if someone insists that they need a particular architecture or implementation pattern for things to work (e.g. an enterprise service bus, message queues, etc.), you should view it with a skeptical eye. Consider whether another approach might not be better.
Isolate unrelated portions of the application from each other structurally as well as logically. Don't just loosely couple or decouple your classes; make them entirely separate projects that must be built separately.
Code to interface, not implementation. If a number of classes all do something similar, make an interface. Don't use abstract base classes as pseudo-interfaces. Depend on the interface and pass that around instead of the individual implementing classes.
Understand the larger scope of the application. What business purpose does it serve? How will it help people, accomplish goals, or improve productivity? Are the things that you're building aligned with that purpose? Make sure you're not building for the sake of building.
Be wary when someone tells you that this is an "enterprise application". This is a loaded term with too many connotations for too many different people. Make sure to be clear about cross-cutting concerns like security, authorization, authentication, service guarantees, et cetera.
Enterprise applications are prone to bloat. Don't be afraid to say "no" to new features, and refactor mercilessly with good unit tests to make sure you're getting the most bang for your buck.
Finally, everything in moderation. Taking any of the above (or anything in general, really) to an extreme is a bad idea. The only thing you should really do in the extreme is moderation itself! :)
I see two fundamental kinds of design activities.
There is a decomposition in primary system pieces. So you've already got some idea of a separation of the presention pieces from the rest of your system. You'll probably have some Business Logic and Persistence too. First important question, how much Business Logic do you really have. Some systems are little more than a thin skin in front of a simple database, hardly any true business logic. Others have very major pieces of Business Logic that are to some extent independent.
If you have major semi-independent pieces they might best communicate via events and message queues. So indentify whether you have pieces that need that kind of decoupled relationship, and that leads to identifying the events and the payloads of those events. Here's where the Fowler referenced in another answer becomes relevent.
Next drill into the Business Logic pieces. Interfaces and Abstract Classes etc. are techniques for structuring the implementation of complexity. Separate your code so that details are hidden and flexibility is enabled. I see this as being an OO design exercise, there are plenty of books about that, for example head first.
To give you a short answer to a big question - don't start with the class design first. Start with the design of components, layers, and make some technology decisions like "do I need a database, and if so, which one". This assumes you have already done some portion of analysis of your problem domain, found some essential use cases etc.
When you are ready with that, it may be a good idea to code a "cut-through" application to verify your architectural decisions. That means, a small application that touches most of your layers while handling only a very small use case. It should be small enough to be easily rewritten/corrected/thrown away when you think parts of your architecture are flawed. That's also a good technique to get a first grip on your class design.