Component Approach in Software Architecture

Component-Based Architecture: From Monolith to Scalable Systems

Component-based architecture treats directories like building blocks on a diagram and dependencies like connecting lines. Each component is a directory of code compiled into a library. Dependencies are managed by the build tool—for instance, crm/core pulls in crm/api and payments/api to integrate with a payment gateway.

This creates natural nesting, much like a file system, while ensuring seamless interoperability. The approach works with any modern build tool and language, scaling from monoliths to microservices.

API and SPI for Data Abstraction

Separate core business logic from infrastructure using the API-SPI pattern. The API is the contract your app exposes (like a CRM interface). The SPI is the contract for external providers (Postgres for storage, TigerBeetle for payments).

Key benefits:

• Core logic stays independent of specific databases or services.
• Swap implementations without rebuilding the core.
• Support multiple providers in a single bootstrap process.

The diagram places core between api and spi, with infrastructure components implementing the SPI.

Bootstrap for App Assembly

Build a bootstrap component as a plug-and-play dependency. It wires SPI implementations to APIs in the app's context. Modern frameworks resolve dependencies automatically; in plain languages, use build config.

Example: A CRM bootstrap connects crm/core and payments/core via a shared context. This streamlines deployment—just add the dependency, and you're good to go.

Evolving to Microservices

For independent scaling, break out the monolith:

• Extract standalone apps for CRM and payments.
• Add a rest-client in CRM that implements the Payments API over HTTP.
• In payments, add a rest-server proxying to payments/core via bootstrap.
• Share common DTOs in rest-common.
• Wrap the client in CRM's bootstrap.

Result: A cluster with bounded contexts, where components scale independently.

Platform Components

Extract shared solutions into a platform to follow DRY principles:

• Postgres and TigerBeetle configs.
• REST client/server communication.
• Auth, async/sync messaging, and storage.

The platform cuts duplication: components plug in ready-to-use setups. Scale reuse from basic to enterprise-grade solutions.

Benefits and Governance

Components enforce clear boundaries per Conway's Law: assign to teams and track interactions.

Lifecycle management: Small components are easy to swap and migrate.

Stay requirement-focused: Abstractions let you pick stacks based on KPIs (performance, cost), not habits.

When to Use It

Adopt from day one: from prototypes to distributed systems. Works with any build tool, scales to repos and teams. Avoid the 'big ball of mud'—components enable smooth evolution.

Key takeaways:

• Granular directories as deployment and responsibility units.
• API/SPI for decoupling from infrastructure.
• Bootstrap for automatic context assembly.
• Platform for max DRY and reuse.
• Seamless monolith-to-microservices transition without core refactoring.

— Editorial Team