Dekomposisi Monolit

A monolithic application is built as a single, indivisible unit. All components like the user interface, business logic, and data access are tightly coupled within one large codebase.

While simple to start with, monoliths can become very complex and difficult to manage as they grow larger.

As monolithic applications grow, they often face significant challenges:

• Slow Development: Large codebases make changes riskier and slow down development cycles.
• Scaling Issues: You can only scale the entire application, even if only one small part needs more resources.
• Technology Lock-in: It's hard to introduce new technologies without rewriting the whole app.
• Deployment Risk: A small change requires redeploying the entire application, increasing risk.

Microservices address these challenges by breaking down an application into small, independent services. Each service focuses on a single business capability, runs in its own process, and communicates via lightweight mechanisms like APIs.

This approach offers greater flexibility, independent deployment, and easier scaling.

One of the most effective ways to decompose a monolith is by identifying distinct business capabilities.

• Think about the core functions your business performs (e.g., "Order Management," "User Profiles," "Payment Processing").
• Each capability becomes an independent microservice. This ensures services are cohesive and loosely coupled.

From Domain-Driven Design (DDD), a Bounded Context defines a clear boundary within which a specific domain model applies.

• Words and concepts (like "Product") have precise meanings only within their specific context.
• For example, a "Product" in an inventory context might differ from a "Product" in a sales context.
• Decomposing along these boundaries helps create services with clear, isolated responsibilities.

The Strangler Fig Pattern involves gradually replacing parts of a monolithic application with new microservices, rather than a big-bang rewrite.

• New functionality is built as separate microservices.
• Requests for new features are routed to the microservices, while old requests still go to the monolith.
• Eventually, the microservices "strangle" or completely replace the monolith. It's a low-risk, incremental approach.

Analyzing where database transactions begin and end can also guide decomposition.

• If a set of operations always occurs together within a single database transaction, it might indicate a single service.
• Operations that don't need to be part of the same transaction could belong to different services.
• This helps minimize the complexity of distributed transactions later on.

Decomposing a monolith isn't without its challenges:

• Increased Complexity: Managing many services is inherently more complex than one.
• Distributed Transactions: Ensuring data consistency across multiple services can be tricky.
• Operational Overhead: More services mean more to deploy, monitor, and troubleshoot.
• Data Duplication: Deciding how to manage shared data across services can be complex.

To ease the transition from monolith to microservices, consider these techniques:

• APIs: Define clear APIs for communication between new services and the old monolith.
• Messaging Queues: Use asynchronous messaging for decoupled communication between services.
• Shared Libraries: Extract common, non-business-specific code into libraries used by multiple services.
• Feature Toggles: Gradually enable new microservice functionality to users.

We've learned that decomposing a monolith addresses challenges like slow development and scaling issues by adopting microservices.

Key strategies for breaking down a monolith include defining services by business capabilities, leveraging Bounded Contexts from Domain-Driven Design, and employing the Strangler Fig Pattern for a gradual, lower-risk migration.

While it introduces new complexities, careful planning and the right tools can make the transition successful.