Introduction to Architectural Partitioning
Architectural partitioning is the process of breaking the system down into layers of technology and responsibility.
Each domain partition is unique; some are back office functions, while some are widely distributed or departmental.
There are a variety of techniques for partitioning your architecture.
Each has specific consequences for your application. For each domain partition you will need to define an architecture.
Architecture before Design
It is critical that architectural partitioning come before object design. The low-level design must support the architectural partitioning.
Different architectures result in different design requirements. Issues such as latency, memory management, and communication change with each architectural choice.
A two-tier design does not directly map to a three- or n-tier design. Each change in the architecture changes the requirements for the low-level design.
Architecture dictates technology requirements
The architecture level choices also constrain the technological options that influence the low-level design.
For instance, a decision to use Java on a server and Visual Basic on the client eliminates the option of Java RMI and leads you toward something like
Likewise, the selection of an object database removes the need for object to relational mapping.
After completing this module, you will be able to:
- Explain the purpose and function of architectural partitioning
- Create architectural partitions and define their behaviors
- Specify how responsibilities are distributed in two-tier, three-tier, and n-tier architectures
- Apply the deployment diagram to model the system architecture