General Architecture Overview and Implementation for Scalable Applications

When a startup begins, developers often choose the simplest stacks such as LAMP or SSH to iterate quickly, but as business complexity grows these monolithic designs become hard to maintain, leading to massive classes, tangled if‑else logic, and painful rewrites.

The proposed solution evolves the classic three‑tier model into three distinct layers: a gateway layer that replaces the traditional controller, a business layer that encapsulates service logic, and a foundation layer that houses data‑access components.

Gateway Layer – Handles different network protocols. For HTTP, Tomcat and Spring MVC already abstract the low‑level details; the gateway controller parses request parameters, invokes the underlying service, assembles the response, and logs exceptions without exposing stack traces. For TCP, frameworks like Netty or Dubbo are used; the gateway parses TCP payloads, forwards calls to business services, assembles results, and performs exception handling, shielding downstream code from protocol specifics.

Business Layer – Consists of three sub‑layers: business services, business processes, and business components. Services expose domain‑specific interfaces (e.g., OrderService , MemberService ) with clearly defined request and response objects. An example is a restaurant order where reusable domain objects such as DishDO and BoardDO are combined into a DishOrderCreateRequest . Processes are broken into parameter‑assembly nodes, rule‑evaluation nodes, and action‑execution nodes, allowing fine‑grained reuse and easier maintenance. Components are abstracted into basic reusable pieces (parameter assembly, rule judgment, action execution) and higher‑level capabilities (e.g., a “send‑SMS” capability composed of parameter assembly + SMS sender).

Foundation Layer – Provides interface definitions and technical components. Interfaces are designed per business intent (e.g., insertUser , cacheUser ) rather than generic CRUD methods, following the principle of programming to an interface. Technical components include data storage (relational databases like MySQL, NoSQL stores, file systems), caching (local memory, Memcached, Redis with varying latency), messaging and scheduling (asynchronous processing vs. timed jobs), transaction management (Spring‑TX), and locking mechanisms (optimistic version fields, pessimistic JDK locks).

The article concludes that this layered, protocol‑agnostic architecture offers strong adaptability for rapidly changing internet services, while cautioning against over‑engineering higher‑level abstractions that may yield low cost‑effectiveness.