Applying Architectural Patterns to Monolith Splitting and System Scalability: Lessons from "Software Architecture with Patterns"

Introduction

Recently I finished reading "Software Architecture with Patterns: Volume 1" and have been involved in the early technical discussions of our company's Extensible Business Framework (EBF). This post combines my reading notes with practical problems encountered at work, using specific scenarios to distill relevant knowledge.

As a business‑oriented developer, I aim to go beyond simple CRUD code and apply GoF design patterns and Domain‑Driven Design (DDD) to achieve sustainable delivery.

Common challenges include deciding where to start when splitting a monolith and how to make an increasingly complex system extensible.

Overview

The book defines a pattern as a repeatable solution derived from experience for a particular context, and it contrasts architectural patterns with GoF design patterns.

Although the book is practical and detailed, its translation is sometimes obscure, and some terminology reflects its 2003 publication date.

In this article we focus on two topics: "Monolith Splitting" and "Improving System Extensibility" using architectural patterns as the analytical framework.

Monolith Splitting

Even though many modern companies use multi‑service architectures, a lightweight monolith often grows heavier as requirements accumulate, leading to tangled code and high maintenance costs.

When a monolith reaches a size that requires many developers, unclear module boundaries and lack of coding conventions cause communication overhead and errors. Physical isolation can mitigate these human factors.

The diagram below illustrates a deteriorated monolith where services from Module A directly invoke DAOs of Module C, creating tight coupling across layers.

Module C cannot control which of its capabilities are called, making impact assessment difficult.

Module A’s Service layer becomes chaotic, and future RPC extraction may affect business logic.

SQL joins across module tables further entangle the code.

Unclear module boundaries make it hard to decide where new features belong.

Relying solely on self‑discipline to enforce boundaries incurs high communication and management costs.

Solution

The problem is essentially "from chaos to structure". Layered, pipe‑and‑filter, and blackboard architectures are suitable; we start with layering.

Each layer (Controller, Service, DAO) is independent and forms a closed loop, following a top‑down, non‑reverse flow.

Controller handles I/O and service entry.

Service assembles business logic, possibly with a Manage layer for DAO composition.

DAO performs database operations.

We need to coordinate layers and ensure each layer’s capabilities are self‑contained.

The System Layer follows the classic Controller‑Service‑DAO model, while the Business Layer focuses on defining modules, minimizing inter‑module dependencies, and aligning splits with business processes.

Modules should have as few mutual interfaces as possible.

Prefer splitting along business workflows to avoid reverse dependencies.

During splitting, prioritize logical module isolation before physical separation.

After splitting, each layer must close its loop and expose interfaces identified by a "business identity" to determine which upstream logic to invoke.

Business identity is a configurable mapping that distinguishes scenarios such as different order types (government procurement, personal, corporate, bidding, group buying) to drive appropriate logic.

In summary, layering transforms chaos into structure, and business identity connects upstream and downstream logic.

Improving System Scalability

As systems become richer and more complex, we seek to extend logic outward and increase adaptability. Common GoF patterns such as Adapter, Decorator, and Strategy are useful.

The book introduces a microkernel architectural pattern that separates a minimal core from extensible features, providing a plug‑in environment.

Although microkernel originates from operating systems, we can adapt it to business systems by treating the core as the minimal set of capabilities and external servers as domain‑specific extensions.

The microkernel supplies core mechanisms, while external servers implement concrete business functions; clients invoke these via the kernel’s interfaces.

The microkernel offers only abstract mechanisms, not concrete policies.

External servers aggregate domain‑specific policies and expose services through the kernel.

Clients (applications) use these services to perform business tasks.

When complexity reaches a threshold, we evaluate whether a microkernel fits our domain. In EBF, the microkernel concept guides the separation of core infrastructure from business capabilities.

Business capabilities (e.g., order creation) should delegate cross‑cutting concerns such as messaging to dedicated domains rather than embedding them directly.

By pushing business standards into the kernel, we enhance overall system adaptability while keeping the core independent of specific applications.

Conclusion

Architectural patterns provide scenario‑driven solutions, ranging from "chaos to structure" to distributed, interactive, and adaptive systems. For monolith splitting or scalability, layering clarifies boundaries and cohesion, while the microkernel pattern offers a way to externalize extensible functionality.

Future articles will fill in missing details, especially regarding the microkernel implementation.

Recruitment

The Zero team of Zhengcai Cloud Technology, based in Hangzhou, has over 300 engineers from Alibaba, Huawei, NetEase, and top universities. We explore cloud‑native, blockchain, AI, low‑code platforms, middleware, big data, and more, contributing to many open‑source projects.

If you want to join a passionate team that builds deep business understanding, robust technical systems, and impactful products, please contact us at zcy‑tc@cai‑inc.com.