Why Architecture Design Matters: Tackling System Complexity with Microservices & DDD

Purpose of Architecture Design

Architecture exists to manage software system complexity. According to John Ousterhout in A Philosophy of Software Design , complexity is any factor that makes software hard to understand or modify. He identifies three concrete manifestations:

Change amplification – a seemingly simple change requires modifications in many places.

Cognitive load – high learning and comprehension cost for developers.

Unknown unknowns – uncertainty about which code changes affect system behavior.

Six Sources of System Complexity and General Mitigations

Performance Complexity arises from both single‑machine (processes, threads, IPC) and cluster‑level concerns. Choosing the right concurrency model (e.g., Nginx multi‑process vs. multi‑thread, JBoss multi‑thread, Redis single‑process, Memcached multi‑thread) requires a careful analysis of latency, throughput, and resource constraints.

Availability High availability is achieved through redundancy. Adding nodes for redundancy introduces challenges such as data consistency, failover orchestration, and the CAP theorem trade‑offs (cannot simultaneously guarantee consistency, availability, and partition tolerance).

Scalability Scalable designs anticipate future change. Two prerequisites are accurate prediction of change and perfect encapsulation of that change (e.g., bounded contexts, stable interfaces).

Cost When hundreds or thousands of servers are required, cost becomes a hard constraint. Reducing server count often forces the adoption of newer technologies (NoSQL, search engines, Hadoop) or architectural innovations such as task decomposition.

Security Security splits into functional security (XSS, CSRF, SQL injection, etc.) and architectural security (network segmentation, firewalls, cloud DDoS mitigation). Both layers must be addressed in the design.

Scale Scale introduces exponential growth in connections. If a system has n features and each pair of features may interact, the total number of interactions is n·(n‑1)/2 , leading to combinatorial complexity as n grows.

Complexity‑Analysis Case Study: University Student‑Management System

The following simplified analysis illustrates how to apply the six‑source framework:

Performance : Low request volume; a single MySQL instance behind Nginx suffices.

Scalability : Limited functional growth; no major scaling concerns.

Availability : Require MySQL master‑slave replication and cross‑datacenter sync to avoid data loss.

Security : Use Nginx ACLs, strong authentication, and database permission controls to protect student privacy.

Cost : Few servers; cost is not a primary driver.

Scale : Minimal data volume; scale‑related complexity is negligible.

Microservices: Benefits and Drawbacks

Microservices isolate failures and enable independent horizontal scaling, improving availability and scalability. However, they also increase overall system complexity, infrastructure cost (each service needs its own deployment pipeline, monitoring, and testing), and latency due to inter‑service communication (REST, RPC, gRPC).

Domain‑Driven Design (DDD) for Controlling Microservice Complexity

DDD provides a systematic way to define clear service boundaries.

Strategic Design

Identify bounded contexts and a ubiquitous language to separate distinct business domains.

Tactical Design

Within each bounded context, model aggregates , entities , value objects , and domain services .

Three‑Step Process for Microservice Boundary Definition

Perform event‑storming to discover domain events, commands, and entities.

Group related entities into aggregates that enforce invariants.

Place each aggregate (or a set of tightly coupled aggregates) into a bounded context , which becomes a microservice.

This approach aligns business models with technical models, allowing the architecture to evolve as business needs change while keeping complexity manageable.

Key Architectural Concepts

Task Allocation vs. Task Decomposition : A load balancer (hardware or software) distributes whole requests to multiple servers (task allocation). When a single server becomes a bottleneck, the workload is split into finer‑grained tasks handled by separate services (task decomposition), enabling targeted scaling.

Change Layer vs. Stable Layer : Encapsulate volatile functionality in a change layer that depends on a stable layer exposing a stable API. This reduces the impact of change amplification.

Abstract Layer vs. Implementation Layer : Use an abstract interface (e.g., strategy pattern) to hide implementation details, allowing new implementations to be added without touching the abstract layer.

References

https://promacanthus.netlify.app/computer-science/architecture/01-%E6%9E%B6%E6%9E%84%E5%A4%8D%E6%9D%82%E5%BA%A6%E4%B8%8E%E4%B8%89%E5%8E%9F%E5%88%99/

https://zhuanlan.zhihu.com/p/372225207

https://www.itcast.cn/news/20220329/17575248138.shtml

https://zq99299.github.io/note-book2/ddd/01/01.html

https://time.geekbang.org/column/article/6990