Hybrid “Big Waterfall + Small Agile” Delivery Model and Microservice Architecture Design Principles

I served as the chief architect for a multi‑billion‑RMB production system of a central state‑owned enterprise, overseeing architecture design and management for a project involving three companies, four teams, and about 100 people.

The delivery process was executed using a hybrid "big waterfall + small agile" model, illustrated in the diagram below, which balances strict milestone contracts with selective agile iterations to reduce delivery risk.

As chief architect I also led architecture management, forming an architect team and a Community of Practice (CoP) to track technical issues, identify risks, and propose solutions. Frequent disputes arose around defining application boundaries, especially in a microservice context.

The system adopts a microservice architecture with front‑end/back‑end separation. Backend services are divided by domain boundaries into sub‑domains, each exposing business capabilities as independent services that include required external resources (databases, files, message queues). The client layer consists of Web front‑end, app front‑end, and other smart terminals, and should remain lightweight, delegating business logic to the backend.

Because front‑end and backend service boundaries rarely align one‑to‑one, a Backend‑for‑Frontend (BFF) layer is introduced between them. The BFF provides UI adaptation (transforming service responses into view models) and service aggregation (combining multiple service calls into a single view model). The BFF together with an API gateway forms the edge layer of the microservice architecture.

Following Conway's Law, the team structure should mirror the system architecture. The article shows a team organization diagram that aligns sub‑domain teams with corresponding microservice boundaries, while noting that BFF responsibilities may be placed with the front‑end team to reduce communication cost, unless Node.js is used.

When forming multiple teams, both business and data boundaries must be respected. Each team owns its front‑end (or micro‑front‑end) and back‑end, delivering vertical domain functionality. Data ownership dictates access: the owner of data provides the corresponding business functions.

Application‑boundary design principles are proposed: align business and data boundaries, align business and responsibility boundaries, assign BFF UI adaptation and aggregation based on the front‑end it serves, and ensure service interfaces are extensible, adhere to the single‑responsibility principle, and favor generic over proprietary designs.

Finally, the article promotes the IDCF DevOps Hackathon, an end‑to‑end DevOps experience combining lean startup, agile development, and CI/CD pipelines, scheduled for February 25‑26, 2023 in Hangzhou.