Designing a Scalable Java Backend: From Gateway to Foundation Layer

1. General Architecture Overview

Simple stacks like LAMP or SSH work for early rapid iteration, but as business logic grows they become hard to maintain, leading to massive classes, tangled if‑else statements, and painful rewrites. Adopting a more adaptable architecture from the start can avoid these pitfalls.

2. General Architecture Implementation

The proposed architecture evolves from the classic three‑tier model (controller → service → DAO) into three distinct layers:

Gateway layer (the entry point for all protocols)

Business layer (encapsulates domain logic)

Foundation layer (provides low‑level technical services)

2.1 Gateway Layer

The gateway processes different network protocols. It abstracts HTTP, TCP, and other protocols so that downstream business logic remains unaware of the caller.

2.1.1 HTTP Requests

HTTP requests from web or mobile clients are handled by Tomcat and Spring MVC, which expose RESTful endpoints. Controllers act as the unified gateway: they parse request parameters, invoke the business service, assemble the response, and log any exceptions without exposing stack traces.

2.1.2 TCP Requests

TCP handling relies on Netty and frameworks such as Dubbo or RocketMQ. The gateway parses TCP payloads, forwards them to the appropriate business service, and returns results, shielding the business layer from transport details.

2.1.3 Summary

The gateway isolates protocol concerns, allowing internal business logic to evolve without affecting external callers and enabling seamless addition of new protocols.

2.2 Business Layer

The business layer hosts the core domain processes and is divided into three sub‑layers:

Business Service

Business Process

Business Component

2.2.1 Business Service

Each domain (e.g., Order, Member) defines a service interface with clear input and output models. Methods are named after business actions (e.g., createOrder, cancelOrder) rather than generic CRUD verbs. Input objects combine shared domain models (DOs) with operation‑specific fields, while output objects may be simple for writes or composite for reads.

2.2.2 Business Process

A business process translates business rules into code, typically consisting of three node types: parameter assembly, rule evaluation, and action execution. For example, creating a restaurant order first assembles a DishOrderDO, applies validation rules, then persists it via DAO.

2.2.3 Business Component

Reusable code fragments are packaged as components, mirroring the three node types. Higher‑level capabilities combine multiple components (e.g., a “send‑SMS” capability consists of a parameter‑assembly component and an SMS‑sending component). Over‑abstracting components is discouraged in fast‑changing domains.

2.3 Foundation Layer

The foundation layer consists of interface definitions and technical components.

2.3.1 Interface Definition

Interfaces are designed around business semantics (e.g., insertUser, cacheUser) rather than generic data‑access verbs, promoting a clear contract between business and technical layers.

2.3.2 Technical Components

Key technical building blocks include:

Data Storage : relational databases (MySQL) for core data, NoSQL (HBase) for logs, and file systems or HDFS for large objects.

Cache : in‑memory (nanosecond), centralized (millisecond) and persistent (hundred‑millisecond) caches such as encache, Memcached, and Redis.

Messaging & Scheduling : asynchronous communication via message queues and scheduled jobs for delayed execution.

Transaction Management : typically Spring‑TX, with careful scoping to keep related DB operations in a single transaction.

Locking : optimistic (version field) and pessimistic (JDK Lock) strategies to control concurrent updates.