Architectures and Frameworks

Our discussion so far has focused mainly on architectures: logical architectures that define the separation of roles in our application and physical architectures that define the locations where our logical tiers will run in various configurations. We've also discussed the use of object-oriented design and the concepts behind distributed objects.

Although all of these are important and must be thought through in detail, we really don't want to have to go through this process every time we need to build an application. It would be preferable to have our architecture and design solidified into reusable code that we could use to build all our applications. What we want is an application framework . A framework codifies our architecture and design in order to promote reuse and increase productivity.

The typical development process starts with analysis, followed by a period of architectural discussion and decision making. After that, we start to design the application: first, the low-level concepts to support our architecture, and then the business-level concepts that actually matter to the end users. With the design completed, we typically spend a fair amount of time implementing the low-level functions that support the business coding that comes later.

All of the architectural discussions, decision making, designing, and coding can be a lot of fun. Unfortunately, it doesn't directly contribute anything to the end goal of writing business logic and providing business functionality. This low-level supporting technology is merely "plumbing" that must exist in order for us to create actual business applications. It's an overhead that in the long term we should be able to do once, and then reuse across many business-application development efforts.

In the software world, the easiest way to reduce overhead is to increase reuse, and the best way to get reuse out of our architecture (both design and coding) is to codify it into a framework.

This doesn't mean that application analysis and design are unimportantquite the opposite ! We typically spend far too little time analyzing our business requirements and developing good application designs to meet those business needs. Part of the reason is that we often end up spending substantial amounts of time analyzing and designing the "plumbing" that supports the business application, and we run out of time to analyze the business issues themselves .

What I'm proposing here is that we can reduce the time spent analyzing and designing the low-level plumbing by creating a framework that we can use across many of our business applications. Is the framework that we'll create in this book ideal for every application and every organization? Certainly not! You'll have to take the architecture and the framework and adapt them to meet your organization's needs. You may have different priorities in terms of performance, scalability, security, fault-tolerance, reuse, or other key architectural criteria. At the very least, though, the remainder of this book should give you a good start on the design and construction of a distributed, object-oriented architecture and framework.