Been out of networking school for a while so initially i though this was dealing with the osi model.(lol.).
Found this maybe it will give you an idea
Spoiler: click to toggle You are designing a complex enterprise application that is composed of a large number of components across multiple levels of abstraction. Problem How do you structure an application to support such operational requirements as maintainability, reusability, scalability, robustness, and security? Forces When structuring your application, you must reconcile the following forces within the context of your environment: Localizing changes to one part of the solution minimizes the impact on other parts, reduces the work involved in debugging and fixing bugs, eases application maintenance, and enhances overall application flexibility. Separation of concerns among components (for example, separating the user interface from the business logic, and separating the business logic from the database) increases flexibility, maintainability, and scalability. Components should be reusable by multiple applications. Independent teams should be able to work on parts of the solution with minimal dependencies on other teams and should be able to develop against well-defined interfaces. Individual components should be cohesive. Unrelated components should be loosely coupled. Various components of the solution are independently deployed, maintained, and updated, on different time schedules. Crossing too many component boundaries has an adverse effect on performance. To make a Web application both secure and accessible, you need to distribute the application over multiple physical tiers. This enables you to secure portions of the application behind the firewall and make other components accessible from the Internet. To ensure high performance and reliability, the solution must be testable
Separate the components of your solution into layers. The components in each layer should be cohesive and at roughly the same level of abstraction. Each layer should be loosely coupled to the layers underneath. Pattern-Oriented Software Architecture, Vol 1 [Buschmann96] describes the layering process as follows: Start at the lowest level of abstraction - call it Layer 1. This is the base of your system. Work your way up the abstraction ladder by putting Layer J on top of Layer J-1 until you reach the top level of functionality - call it Layer N. Figure 1 shows how this layering scheme would look.
Figure 1: Layers Structure The key to Layered Application is dependency management. Components in one layer can interact only with peers in the same level or components from lower levels. This helps reduce the dependencies between components on different levels. There are two general approaches to layering: strictly layered and relaxed layered. A strictly layered approach constrains components in one layer to interacting only with peers and with the layer directly below. If the application is layered as shown in Figure 1, for example, Layer J can only interact with components from Layer J-1, Layer J-1 can only interact with Layer J-2, and so on. A relaxed layered application loosens the constraints such that a component can interact with components from any lower layer. Therefore, in Figure 1, not only can Layer J interact with Layer J-1, but with layers J-2 and J-3. The relaxed approach can improve efficiency because the system does not have to forward simple calls from one layer to the next. On the other hand, the relaxed approach does not provide the same level of isolation between the layers and makes it more difficult to swap out a lower layer without affecting higher layers. For large solutions involving many software components, it is common to have a large number of components at the same level of abstraction that are not cohesive. In this case, each layer may be further decomposed into one or more cohesive subsystems. Figure 2 demonstrates a possible UML notation for representing layers that are composed of multiple subsystems.
Figure 2: UML representation of layers composed of subsystems The basic Layered Application pattern is often augmented with the following techniques: Layer Supertype[Fowler03]. If the components in the layer share a set of common behaviors, you extract those behaviors into a common class or component from which all the components in the layer inherit. Not only does this ease maintenance and promote reuse, it also reduces the dependencies between layers by allowing the common behaviors to be invoked through a runtime reference to the supertype instead of a specific component. Abstract interface. An abstract interface is defined for each component in a layer that is called by components in a higher level. The higher layers access the lower-level components through the abstract interfaces instead of calling the components directly. This allows the implementation of the lower-level components to change without affecting the higher-level components. Layer Facade. For larger systems, it is common to use the Facade patternto provide a single unified interface to a layer or subsystem instead of developing an abstract interface for each exposed component [Gamma95]. This gives you the lowest coupling between layers, because higher-level components only reference the facade directly. Be sure to design your facade carefully. It will be difficult to change in the future, because so many components will depend on it. Dynamics There are basically two modes of interaction within the layered application: Top-down Bottom-up In the top-down mode, an external entity interacts with the topmost layer of the stack. The topmost layer uses one or more services of the lower-level layers. In turn, each lower level uses the layers below it until the lowest layer is reached.
.
|