How to start with class design for an enterprise application?

Question

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?

Answer 1

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! :)