Partitioning the "n-tier Architecture" using the Layering Approach

Partitioning in an "n-tier architecture" using the "layering approach" in systems design involves structuring a software application into logically separated sections, each addressing a specific concern or set of functionalities. This model typically includes layers such as presentation, business logic, and data access layers. Additional layers may be added, such as a service layer or caching layer, depending on the application's complexity. Each layer interacts with the adjacent layer through well-defined interfaces, promoting modularity, scalability, and ease of maintenance. This approach ensures that changes in one layer have minimal impact on others, aiding in more efficient development and easier debugging.

• N-tier Architecture:
  By now you see a pattern forming. If you can split a system into two tiers, then three tiers, then why not 'n-tiers?'
  In fact, if you look again at the three-tier architecture you will realize that I lied to you. It is actually five tiers, three functional tiers and two interface tiers. But wait, you say, an interface is just a communication protocol, right? Not always.

One of the first tasks in a project is to set the context and the scope of the proposed application. You need to answer questions such as the following:

1. What functionality do we need to include and exclude?
2. How does this system relate to other systems in our architecture?
3. Who will use the system?
4. Who or what does the system depend on?
5. What products and/or results does the system provide?
6. Why do the users/other systems need the specific set of features that this system provides?

Then think of the system in terms of encapsulation, which asserts that to use an object, you need know only its purpose and its interfaces, not its internal implementation. As long as the purpose and the interfaces of the system remain unchanged, the internal functionality of the object or system may be replaced or enhanced without affecting the entities that access the functionality. The priority in defining a system is to define its purpose and the required interfaces. The purpose is the target of the project justification. The interfaces are the channels of communication between the actors outside the system and the features of the system itself, the use cases. Working inward from these fundamental requirements, each feature provides the context for all subsequent modeling of the system's internal behavior. The Use Case diagram provides the means to model the system in precisely this manner. The diagram consists of six very simple graphics that represent actors and use cases, and the different types of relationships between them, namely associations, 1) include and 2) extend relationships, and generalization. The goal of the diagram is to provide an external view of the relationship between the system and the outside world. It is a very flat diagram, providing only a surface-level, or black-box, view of the system. In a very real sense, the Use Case diagram is an encapsulated view of a system.

For example, imagine an interface between an object server and a relational database server. The interface is actually a layer of programming to handle the mapping, marshalling, and routing of data between the two partitions. In fact, this type of requirement is so common that it has resulted in the development of resources like ODBC and JDBC, standard interface components. Or better yet, consider the CORBA standard, the sole purpose of which is to provide a standard interface service between distributed system components.

• Multiple Partition Possibilities:
  There is no real limit to the number of tiers or partitions that are possible other than performance, technology, and good design. The driving principles should always be
  1. high cohesion and
  2. loose coupling, along with
  3. performance and system integrity.
  In the next lesson you will learn three ways that architectural partitioning has continued to expand our concept of system design by the continued application of the simple pattern for distributing responsibilities.