1.2 Layered Architecture & MVC Pattern

Learning Goal:
• Grasp the concept of layered architecture and the MVC pattern as a practical design approach.

Detailed Content:
• What is a layered architecture: Presentation, Business Logic, Data Layer
• MVC structure: Model, View, Controller responsibilities
• How layers and MVC combine in web applications (Spring Boot / Flask examples)
• Drawing simple system flows
• Exercise: break down sample requirements into layers

1.2.1 Understanding Layered Architecture

One of the most widely used ways to structure a software system is by organizing it into distinct layers. A layered architecture divides a system into horizontal slices, each with its own clear purpose and boundaries. The most common form includes three core layers: the Presentation Layer, the Business Logic Layer, and the Data Layer.

The Presentation Layer is the outermost layer that directly interacts with the user. It is responsible for handling input and output—what the user sees and how they interact with the system. This includes web pages, mobile screens, or any graphical interface.

Beneath it lies the Business Logic Layer, which is the brain of the application. This layer processes the rules, calculations, and workflows that define how the system should behave. It decides what to do with user input and orchestrates data flows between the Presentation and the Data Layer.

Finally, the Data Layer handles all operations related to data storage and retrieval. Whether the data is stored in a relational database, a NoSQL system, or a file, this layer abstracts away the details of how information is persisted and retrieved. By isolating data access, the system becomes easier to maintain and adapt to new storage technologies without rewriting core business rules or presentation details.

This separation of concerns makes layered architecture especially powerful. Each layer has a specific responsibility, making it easier for teams to work in parallel and for the system to evolve over time. If a change is needed in the database structure, the Data Layer absorbs most of the impact, while the Presentation and Business Logic Layers stay largely untouched.

1.2.2 The MVC Pattern: Model, View, Controller

While layered architecture describes horizontal slices of a system, the MVC (Model-View-Controller) pattern introduces a practical way to organize user-facing applications, especially web apps and desktop GUIs. MVC is about splitting an application’s logic into three distinct roles to manage complexity and keep code manageable.

The Model represents the data and the business rules. It holds the state of the application and the logic for how that state can change. For example, in a blog application, the Model would handle what a “Post” is, what its attributes are, and how posts are saved or retrieved from the database.

The View is responsible for presenting information to the user. It takes the data prepared by the Model and formats it in a way that users can understand. In a web application, this could be an HTML page rendered with template engines like Thymeleaf, Jinja2, or EJS.

The Controller sits in the middle, acting as the glue between the user’s actions and the system’s response. It handles incoming requests, processes user input, calls the necessary business logic, interacts with the Model, and then chooses which View to display next.

By cleanly dividing these responsibilities, MVC prevents messy codebases where user interface logic, data management, and application flow are tangled together. This separation makes it much easier to test, reuse, and change parts of an application without breaking unrelated features.

1.2.3 Combining Layers and MVC in Web Applications

In practice, layered architecture and the MVC pattern often work hand in hand—especially in modern web frameworks like Spring Boot for Java or Flask for Python. In a typical Spring Boot web application, the Presentation Layer maps closely to the View and Controller in MVC. The web controller handles HTTP requests and responses, routing them through the appropriate business services. These services form the Business Logic Layer, containing the domain rules and core operations. The repositories or DAOs (Data Access Objects) belong to the Data Layer, handling interactions with databases like MySQL or PostgreSQL.

For example, when a user submits a form on a website, the request is captured by the Controller. The Controller validates the input, passes it to a Service in the Business Logic Layer, which performs checks and processes the data. If necessary, the Service calls a Repository in the Data Layer to fetch or store data. Finally, the result is sent back through the Controller to render a View, presenting a response page or redirecting the user.

In Flask, the pattern is similar, though lighter. Routes act as Controllers, calling functions that handle input and output, using Models to talk to databases like SQLite, and rendering Views through template engines like Jinja2.

This blending of layers and MVC keeps responsibilities clear while maintaining flexibility. It shows why understanding both the big-picture layered approach and the practical MVC pattern is so useful for developers building real-world web systems.

1.2.4 Drawing Simple System Flows

One of the best ways to internalize layered architecture and MVC is to visualize them. Even a simple sketch helps make the abstract structure concrete. For example, drawing a basic diagram for a blog app might show the Presentation Layer with Controllers and Views on top, connected to a Service Layer that talks to Models and Repositories underneath.

Such flow diagrams help clarify how a user action—like clicking a “Submit” button—travels through the layers: the request hits the Controller, the Controller delegates logic to a Service, the Service interacts with the Repository, and the Repository fetches or stores data. The result flows back up through the same path to the user interface.

Practicing these simple system flows is an excellent habit for any aspiring architect or developer. It trains the mind to think about clear boundaries, defined responsibilities, and predictable data movement—foundations that support maintainable, scalable applications.