Декомпозиция монолитов

A monolithic application is built as a single, unified unit. All its components – user interface, business logic, and data access layer – are tightly coupled and run within a single process.

Think of it like a single, large building containing everything. They are simpler to develop initially but can become difficult to manage and scale as they grow.

In contrast, a microservices architecture breaks down an application into a collection of small, independent services. Each service runs in its own process and communicates with others, usually through lightweight mechanisms like an API.

• Independent: Services can be developed, deployed, and scaled on their own.
• Specialized: Each service focuses on a single business capability.
• Resilient: A failure in one service doesn't necessarily bring down the entire system.

Decomposing a monolith into microservices offers several key advantages, especially as your application grows:

• Scalability: Scale individual services based on demand, not the entire application.
• Flexibility: Use different technologies (languages, databases) for different services.
• Faster Development: Smaller codebases are easier for teams to manage and deploy independently.
• Improved Resilience: A bug in one service won't crash the entire system.

The "Strangler Fig Pattern" is a popular strategy for gradually decomposing a monolith. It involves building new microservices around the existing monolith and slowly redirecting traffic to them.

Eventually, the new services "strangle" the old functionality until the monolithic part can be removed. This reduces risk by allowing incremental changes.

A crucial step in decomposition is identifying Bounded Contexts. This concept from Domain-Driven Design (DDD) helps define the natural boundaries of your new microservices.

• What it is: A logical boundary where a specific domain model and its language are defined and applicable.
• Why it's useful: Helps ensure each service has a clear, independent responsibility and its own specialized understanding of data.
• Example: A "User Management" context handles user profiles, while an "Order Processing" context manages orders.

One of the trickiest parts of decomposing a monolith is splitting its database. Each microservice should ideally own its data schema, meaning it has its own dedicated database or a dedicated schema within a shared database.

• Why: Decouples services, allows independent data evolution.
• Challenges: Maintaining data consistency across services, managing complex transactions.
• Strategy: Gradually extract tables relevant to a new service into its own database.

Let's consider a monolithic application with user management. To extract a UserService:

1. Identify all user-related code (registration, login, profile updates) in the monolith.
2. Create a new, separate UserService microservice.
3. Move the user data (e.g., users table) to its own database, owned by the new service.
4. Modify the monolith to call the UserService API instead of directly accessing user data.

This is a gradual process, often using the Strangler Fig Pattern.

Once you have multiple microservices, they need to communicate. For initial decomposition, direct API calls (e.g., REST over HTTP) are common. A user service might expose endpoints for other services to retrieve user details.

As systems grow, more advanced patterns like message queues become essential for asynchronous communication. We'll explore these in the next lesson!

Today, we explored how to break down monolithic applications into smaller, manageable microservices. We learned about:

• The core differences between monoliths and microservices.
• Benefits like improved scalability, flexibility, and resilience.
• Strategies like the Strangler Fig Pattern and identifying Bounded Contexts.
• The challenges of database decomposition and initial service communication.

Next up, we'll dive deeper into how these services communicate effectively!