06 Quiz: Architectural Patterns

The Model in MVC is responsible for data and business logic. It manages the application’s data, enforces business rules, and is completely independent of the user interface. The View handles display (A), the Controller handles user input coordination (C), and rendering templates is a View responsibility (D).

The Controller acts as the coordinator in MVC. It receives user input from the View, processes it (potentially updating the Model), and triggers View updates when the Model changes. Data storage is infrastructure-related, visual layout is the View’s job, and network management is typically separate from the MVC triad.

The key benefit of MVC separation is enabling parallel development. UI designers can work on Views without understanding business logic, while developers can work on Models without touching the interface. This separation also enables testing Models independently of UI and using the same Model with multiple Views (web, mobile, CLI).

Django uses different terminology but the same pattern. In Django: the Model is still the Model, the Template corresponds to MVC’s View (presentation), and Django’s View corresponds to MVC’s Controller (handling requests and coordinating). This naming difference often confuses developers, but the underlying separation of concerns is identical.

Dependencies in layered architecture must flow downward only. The Presentation layer can depend on Business, Business can depend on Data, but never the reverse. This ensures that lower layers remain independent and reusable. The Data layer should never know about the UI, and the Business layer shouldn’t depend on how data is presented.

A UI component (Presentation layer) directly querying the database (Data layer) violates the “no skipping layers” rule. The Presentation layer should go through the Business layer, which then accesses the Data layer. Controllers calling Services, Repositories using ORMs, and Services validating rules are all proper layer interactions.

Proper layered architecture isolates technology changes to specific layers. When switching databases, only the Data Access layer (repositories, connection code) needs to change. The Business layer continues to call the same repository interfaces, and the Presentation layer is completely unaffected. This isolation is a key benefit of the pattern.

Domain logic belongs in the Business/Domain layer. This includes calculations, validations, and business rules like computing maximum slope from measurements. Placing such logic in the Presentation layer couples it to the UI, making it untestable and unreusable. The Data layer should only handle data storage and retrieval.

In client-server architecture, the server is the authority for business rules, data validation, and security enforcement. While clients may perform validation for better user experience, the server must always validate because clients can be bypassed or manipulated. Relying on client-side validation alone creates security vulnerabilities.

Microservices are appropriate for large teams that need to work independently, when different features have different scaling requirements, or when technology diversity is needed. The lecture explicitly warns against microservices for small teams, early-stage products, and simple domains because the coordination overhead outweighs the benefits.

Monolithic architecture offers simpler deployment (deploy once, not coordinate multiple services) and lower operational complexity. You deploy the entire application as one unit without worrying about service discovery, network latency between services, or distributed debugging. Independent scaling, technology diversity, and failure isolation are advantages of microservices, not monoliths.

A technical spike is time-boxed research (e.g., 2 days maximum) to investigate architectural questions before committing. For example, investigating PostgreSQL vs SQLite by building a proof-of-concept and measuring performance. This provides informed decisions rather than guesswork. Spikes are not about rushing or extensive documentation.

Emergent architecture means making enough decisions to start (language, framework, basic structure), implementing working software, and refactoring as patterns emerge. It’s not “no planning” - you still make initial decisions. It’s not “all upfront” - you avoid over-designing for hypothetical futures. Architecture evolves through retrospectives and continuous improvement.

Architectural patterns are valuable because they are discoveries of recurring structures in successful systems - not inventions. They provide: proven solutions, shared vocabulary for communication, known trade-offs you can analyze, and community support. They don’t eliminate custom decisions or make applications identical - you still need to adapt patterns to your specific context.