Hybrid “Big Waterfall + Small Agile” Delivery Model and Application Boundary Design in Large‑Scale Microservice Architecture

The author, a former chief architect for a multi‑billion‑yuan production system of a central state‑owned enterprise, led a project involving three companies, four teams and about 100 engineers, overseeing overall architecture design and management.

To meet strict contractual milestones while retaining agility, the author defined a hybrid delivery model called “big waterfall + small agile”, combining sequential phase deliveries with selective agile iterations to reduce risk.

Architecture management was performed through a dedicated architect team and a Community of Practice (CoP) that held regular meetings to track technical issues, identify risks, and propose solutions across distributed teams in Chengdu, Beijing, and Hangzhou.

A key challenge was defining clear application boundaries in a microservice architecture, especially the mismatch between front‑end and back‑end service scopes.

The system adopted a front‑end/back‑end separated microservice architecture: back‑end services are divided by domain boundaries into sub‑domains, each microservice being an independent business unit with its own data stores, files, or message queues; the front‑end layer includes Web, app, and other smart‑terminal clients.

Front‑end design follows a “light front‑end, heavy back‑end” principle, keeping business logic in the back‑end to avoid duplication and performance issues on limited front‑end resources.

Because front‑end and back‑end boundaries often do not align one‑to‑one, a Backend‑for‑Frontend (BFF) layer is introduced to provide interfaces tailored to front‑end needs, handling UI adaptation and service aggregation.

The BFF layer, together with an API gateway, forms the edge layer of the microservice application architecture.

Following Conway’s Law, the team structure mirrors the system architecture: separate front‑end and back‑end teams, with sub‑domain teams aligned to microservice boundaries, while the BFF layer may be owned by the front‑end team or a dedicated team depending on communication cost and skill requirements.

Application boundary design principles are proposed: align business and data boundaries, align responsibilities with team capabilities, assign BFF responsibilities based on the front‑ends it serves, and adhere to service‑interface design rules such as single‑responsibility, extensibility, and generic over proprietary interfaces.

Finally, the article includes a promotional notice for a DevOps Engineer certification class starting on June 20, encouraging readers to scan the QR code and register.