Hello! Welcome to the "Software Architectural Patterns" module. This is where we start looking at the big picture—how to structure an entire software system.
In our last module, we concluded by looking at how to choose the right database, often leading to a "polyglot persistence" model where different databases are used for different jobs. This idea of choosing the right tool for the job based on trade-offs is the essence of software architecture. Now, we're going to apply that same thinking to the overall structure of our application.
Your learning outcome for this lesson is to compare monolithic, layered, and modular architectural styles, analyzing their pros and cons. We will dissect these foundational patterns to understand how they shape a system's development, deployment, and maintenance. This is a crucial first step in developing the "architectural mindset" you're aiming for.
1. The Monolith: One Application, One Unit
The term "monolith" often gets a bad rap, but it's the most traditional and straightforward way to build an application. The defining characteristic of a monolithic architecture is that the entire application is built, packaged, and deployed as a single unit. If you've worked with a standard Laravel or Ruby on Rails application, you have worked on a monolith.
However, "monolith" doesn't mean "unstructured." The most common way to organize a monolith is using a Layered Architecture (also known as N-Tier).
Layered Architecture: Separation by Technical Concern
A layered architecture organizes code into horizontal layers based on technical function. Think of it like a cake with distinct layers for presentation, business logic, and data access.
Layered vs Modular vs Microservices...
To start, let's get a clear definition of the layers. This article provides a concise breakdown of a typical layered architecture.
Read only the section titled '2. Layered (N-Tier) Architecture'. Pay attention to the specific responsibilities of each layer: Presentation, Application, Domain, and Infrastructure.
Now, let's see how this structure behaves as a single deployable unit and what its main characteristics are.
Monolithic, N-Tier, Microservices explained with comparison and example - Software Architecture
This video provides a great practical explanation of both a simple monolith and how it's typically organized into an N-Tier (Layered) structure. It will help you visualize the concepts we've just defined.
Please watch the following two segments: Monolithic Architecture (02:16 - 03:56): This covers the basic concept of a monolith as a single codebase and deployment artifact. N-Tier Architecture (03:56 - 05:42): This explains how the monolith can be split into logical layers that might have separate codebases but are often part of the same deployable system logic.
As a full-stack developer, the layered style is likely very familiar. For example, in a typical web application:
- Your React components form the Presentation Layer.
- Your API controllers and application services in Laravel form the Application Layer.
- Your core business models and rules are the Domain Layer.
- Database-specific code (like Eloquent models or direct SQL queries) is part of the Infrastructure Layer.
While this provides good technical organization, it has a key drawback: a single business feature (e.g., "add item to cart") requires changes across all layers. A frontend developer touches the UI, a backend developer touches the API and business logic, and a database expert might need to alter the schema. This creates dependencies across teams and can slow down development as the application grows.
2. The Modular Monolith: Separation by Business Domain
What if we could keep the simplicity of deploying a single application, but organize the code in a way that better reflects our business? This is the goal of the Modular Monolith.
Instead of horizontal layers for technical concerns, a modular monolith is organized into vertical slices based on business domain or capability. Each module encapsulates everything needed for a specific feature—its own UI components, business logic, and data access code.
To dive deeper into this powerful concept, the following video provides an excellent explanation.
Lesson 159 - Modular Monolith Architecture
Let's explore the Modular Monolith in detail. This video clearly explains its core principles and how it differs from a layered approach.
Please watch these segments: Definition (00:46 - 02:07): Focus on the key idea that functionality is grouped by domain area, not technical category. Advantages (03:19 - 04:58): Note when this architecture is a good fit, particularly regarding team structure and domain-based changes. Disadvantages (04:58 - 06:39): Understand its limitations, especially concerning scalability and agility.
The difference in code organization is profound. Let's compare the file structures you might see. This will feel very concrete given your development background.
Monolith, Modular Monolith, and Microservices: A Comparison
This article provides a fantastic, code-level illustration of the difference between a traditional monolith and a modular one. The example file structures make the architectural concepts tangible.
Read the sections 'Monolith' and 'Modular Monolith'. Pay close attention to the 'Example file structure' in each section. Notice how the first is organized by component type (controllers, models), while the second is organized by business feature (users, products).
In a modular monolith, the "add item to cart" feature would live almost entirely within a "Checkout" or "Cart" module. This high cohesion and low coupling between modules allows different teams to work on different business domains with much less friction.
Test your understanding!
Imagine you are building a new e-commerce application. The initial team is small, but you anticipate adding distinct new business capabilities later, like 'Warehouse Management', 'Customer Loyalty Program', and 'Marketing Analytics'.
Would you advocate for starting with a Layered Monolith or a Modular Monolith? Justify your choice based on team structure and the application's expected evolution.
Show answer
A Modular Monolith is the stronger choice here.
Justification:
- Future Evolution: The application is expected to grow by adding distinct business domains ('Warehouse Management', 'Loyalty'). A modular structure allows you to build these as self-contained modules from the start, making the codebase much easier to navigate and maintain as it grows.
- Team Structure: As the company grows, you can assign cross-functional teams to own entire modules (e.g., the "Loyalty Team"). This aligns team structure with the architecture, reducing cross-team dependencies.
- Path to Microservices: If, in the future, the 'Warehouse Management' module experiences massive load and needs to be scaled independently, its clean boundaries make it a much easier candidate to extract into its own microservice than if its logic were spread across multiple layers in a layered architecture.
3. Comparative Analysis: Making the Trade-Offs
There is no single "best" architecture. The choice is a series of trade-offs. Let's summarize the pros and cons of these monolithic styles.
| Feature | Layered Monolith | Modular Monolith |
|---|---|---|
| Primary Organization | Technical Concern (UI, Logic, Data) | Business Domain (Users, Products, Orders) |
| Coupling | High coupling for business features (cuts across all layers). | Low coupling between modules. High cohesion within modules. |
| Team Structure | Encourages technically specialized teams (frontend, backend). | Encourages cross-functional, feature-oriented teams. |
| Maintainability | Can become a "big ball of mud" as the application grows, since there are no strong boundaries between features. | Easier to maintain and reason about at scale due to clear module boundaries. |
| Deployment | Simple (single deployment unit). | Simple (single deployment unit). |
| Path to Microservices | Difficult. Feature logic is tangled across layers. | Simpler. A well-defined module is a natural candidate for extraction. |
The following image provides a concise, high-level comparison of these styles against a potential future step: microservices. Focus on the columns for "Monolith" (which you can consider our "Layered Monolith") and "Modular Monolith".
Ultimately, the choice comes down to your project's context.
- A Layered Monolith is great for small projects, prototypes, or applications with a very stable and well-understood domain. Its simplicity is its strength.
- A Modular Monolith is an excellent choice for medium-to-large applications that need to remain as a single deployable unit but require better organization to manage complexity and facilitate parallel work by multiple teams. It strikes a balance between operational simplicity and architectural scalability.
Conclusion
In this lesson, we dissected the monolithic architecture, revealing that it's not a single pattern but a category that includes distinct styles. Understanding the difference between organizing by technical layers versus business modules is a fundamental architectural skill.
Key Takeaways:
- Monoliths are defined by being a single unit of deployment, which simplifies operations.
- Layered Architecture separates concerns by technical function. It's simple to start with but can become hard to maintain as features become intertwined across layers.
- Modular Monolith Architecture separates concerns by business domain. It requires more discipline but offers better scalability for development teams and a clearer path for future evolution.
- The choice between them is a strategic decision based on project complexity, team size, and long-term goals.
Preview of the Next Lesson:
We've seen how the modular monolith provides a stepping stone toward greater separation. In the next lesson, we will take the ultimate step and explore what happens when modules become fully independent, separately deployable services. We will analyze the principles and trade-offs of microservices vs. monolithic architectures, giving you a complete picture of this critical architectural decision.