System Architecture Thinking cho người mới bắt đầu
Layered Architecture và những gì bạn cần biết
Hầu hết những hệ thống trở nên phức tạp không phải vì đội ngũ chọn sai kiến trúc ngay từ đầu, mà vì họ không hiểu rõ hệ quả của kiến trúc mình đang sử dụng. Điều này đặc biệt đúng với Layered Architecture – mô hình kiến trúc quen thuộc, dễ tiếp cận, và cũng dễ gây ra nhiều rủi ro nhất nếu không được kiểm soát.
Với nhiều người mới bắt đầu, kiến trúc hệ thống thường được xem là phần việc của kỹ thuật, phải là senior architecture mới hiểu rõ được. Nhưng thực tế, kiến trúc ảnh hưởng trực tiếp đến những thứ mà PM/BA chịu trách nhiệm hàng ngày:
Tốc độ delivery,
Khả năng mở rộng sản phẩm,
Chi phí vận hành,
Và mức độ rủi ro khi thay đổi.
Vì vậy, System Architecture Thinking không phải là học để vẽ sơ đồ, mà là học để đánh giá tác động dài hạn của những quyết định tưởng như rất sớm và rất nhỏ.
Trong quyển sách Software Architecture Patterns của Mark Richards, ông chỉ ra rằng: trong nhiều dự án, khi không có kiến trúc được định nghĩa rõ ràng, đội ngũ thường vô thức quay về một lựa chọn an toàn – Layered Architecture (hay còn gọi là N-tier) .
Vấn đề là: Layered Architecture rất dễ bắt đầu, nhưng cũng rất dễ đi sai.
Layered Architecture là gì?
Layered Architecture tổ chức hệ thống thành các lớp ngang, mỗi lớp đảm nhận một vai trò rõ ràng:
Presentation layer (UI / API)
Business layer (logic nghiệp vụ)
Persistence layer (data access)
Database layer
Request đi từ trên xuống, response đi ngược lại. Mô hình này tạo cảm giác đúng, clean, và rất phù hợp với tư duy phân tầng trong quản lý và nghiệp vụ.
Chính vì sự quen thuộc đó, Layered Architecture trở thành lựa chọn mặc định trong nhiều đội ngũ, kể cả khi không có một quyết định kiến trúc rõ ràng nào được đưa ra. Khi không ai chủ động thiết kế kiến trúc, hệ thống thường tự nhiên trôi về mô hình này – không phải vì nó tối ưu, mà vì nó dễ bắt đầu nhất.
Vì sao Layered Architecture dễ hiểu?
Layered Architecture có rất nhiều điểm hấp dẫn:
Mapping rất logic với tư duy nghiệp vụ
Dễ giải thích với stakeholder
Dễ chia task cho team
Dễ onboard thành viên mới
Quan trọng hơn, mô hình này phù hợp với cấu trúc tổ chức truyền thống:
team frontend
team backend
team database
Đây là lý do nó thường trở thành lựa chọn mặc định trong giai đoạn đầu của dự án.
Nhưng vấn đề bắt đầu từ đâu?
1. Big Ball of Mud – khi “có layer nhưng không có kiến trúc”
Một trong những rủi ro lớn nhất của Layered Architecture là hiện tượng “Big Ball of Mud”. Trên lý thuyết, mỗi layer có một trách nhiệm rõ ràng. Nhưng trong thực tế, nếu không có ranh giới đủ chặt chẽ, business logic bắt đầu rò rỉ lên presentation layer, data access xuất hiện trong business layer, và các lớp dần phụ thuộc lẫn nhau một cách khó kiểm soát. Hệ thống vẫn có “layer”, nhưng kiến trúc thật sự đã biến mất, chỉ còn lại cấu trúc thư mục.
Mark Richards gọi đây là anti-pattern phổ biến nhất. Khi không có quy ước rõ ràng về trách nhiệm của từng layer, code sẽ dần trở nên:
tightly coupled
khó thay đổi
khó dự đoán tác động khi sửa một phần
Kết quả là một hệ thống:
có vẻ được chia layer,
nhưng thực chất là một mớ hỗn độn được chia folder .
📌 Góc nhìn
Nếu bạn không còn trả lời được các câu hỏi như:
Hệ thống này scale thế nào?
Thay đổi feature A ảnh hưởng tới đâu?
Deploy có rủi ro không?
→ rất có thể hệ thống đã rơi vào Big Ball of Mud
2. Architecture Sinkhole – request đi qua nhưng không làm gì
Một rủi ro khác của Layered Architecture là architecture sinkhole.
Đây là tình trạng:
request đi qua nhiều layer
nhưng mỗi layer chỉ chuyển tiếp dữ liệu
gần như không có xử lý giá trị nào .
Mark Richards gợi ý nguyên tắc 80–20:
~20% request chỉ pass-through → chấp nhận được
nếu phần lớn request chỉ đi xuyên layer → kiến trúc đang có vấn đề
📌 Góc nhìn
Đây là lúc bạn nên đặt câu hỏi:
Chúng ta đang thêm layer để làm rõ trách nhiệm,
hay chỉ để “cho đúng mô hình”?
3. Xu hướng monolith hóa rất mạnh
Layered Architecture cũng có một xu hướng rất tự nhiên: monolith hóa, ngay cả khi:
presentation và business được deploy riêng
hay database được tách biệt
Mark Richards cảnh báo rằng mô hình này thường gặp vấn đề ở:
deployment
scalability
performance
reliability .
📌 Đây là rủi ro dài hạn, không xuất hiện ngay lúc MVP.
Vậy Layered Architecture có xấu không?
Câu trả lời là Không. Layered Architecture là:
một điểm khởi đầu tốt
đặc biệt khi bạn chưa chắc hệ thống sẽ phát triển theo hướng nào .
Vấn đề không nằm ở mô hình, mà nằm ở việc coi nó là điểm đến cuối cùng.
Bạn nên làm gì với Layered Architecture?
Thay vì hỏi “có dùng Layered Architecture không?”, hãy hỏi:
Ranh giới giữa các layer có được định nghĩa rõ không?
Logic nghiệp vụ có thực sự nằm ở business layer không?
Bao nhiêu request đang chỉ pass-through?
Chúng ta có lộ trình thoát khỏi monolith khi hệ thống lớn lên không?
👉 Đây không phải câu hỏi kỹ thuật thuần túy.
👉 Đây là câu hỏi quản trị rủi ro sản phẩm.
Một số ví dụ về Layered Architecture
Ví dụ 1: Hệ thống Web Application truyền thống (CRUD / Business App)
Mô tả kiến trúc
Đây là ví dụ kinh điển nhất của Layered Architecture:
Presentation layer
Web UI (React / Angular / Blade / Thymeleaf)
REST API Controllers
Business layer
Service classes
Xử lý nghiệp vụ (validate, rule, workflow)
Persistence layer
Repository / DAO
ORM (Hibernate, Sequelize, Eloquent)
Database
MySQL / PostgreSQL
Vì sao kiến trúc này được dùng rất nhiều?
Phù hợp với nghiệp vụ CRUD
Mapping 1–1 với yêu cầu BA
Team dễ phân công:
FE làm UI
BE làm service
DB team quản lý schema
Insight
Rất nhiều hệ thống ERP, CRM, Admin Portal hiện nay vẫn chạy theo mô hình này.
Rủi ro thường gặp:
Business logic bị đẩy lên controller
Repository bị dùng trực tiếp từ UI
Dẫn đến Big Ball of Mud
👉 Câu hỏi nên hỏi: “Logic nghiệp vụ này đang nằm ở đâu?”
Ví dụ 2: E-commerce platform giai đoạn đầu (Monolith Layered)
Mô tả kiến trúc
Một hệ thống e-commerce nhỏ thường bắt đầu như sau:
Presentation:
Web storefront
Admin dashboard
Business:
Order service
Pricing logic
Promotion rules
Persistence:
Order repository
Product repository
Database:
Single relational DB
Hình dưới thể hiện quá trình phát triển của một kiến trúc E-commerce từ Monolith → Monolith Layering → N-tiering → Microservices → Headless.
Vì sao hợp lý ở giai đoạn đầu?
Tốc độ ra thị trường nhanh
Dễ thay đổi business rules
Ít chi phí vận hành
Khi nào bắt đầu có vấn đề?
Order logic + promotion + inventory chồng chéo
Mỗi thay đổi nhỏ → test toàn bộ flow checkout
Deploy phải deploy cả hệ thống
Insight
Rất nhiều nền tảng e-commerce không chết vì traffic,
mà chết vì logic nghiệp vụ trở nên quá phức tạp trong một monolith layered.
👉 Đây là lúc chúng ta nên nghĩ đến Modular Monolith, không phải microservices ngay.
Ví dụ 3: Enterprise system (Banking / Insurance / Government)
Mô tả kiến trúc
Các hệ thống enterprise thường có layer rất dày:
Presentation:
Web portal
Internal tools
Application layer:
Orchestration
Transaction management
Domain layer:
Business rules
Policy logic
Integration layer:
Connect legacy systems
ESB / middleware
Persistence + DB
Vì sao họ vẫn dùng Layered Architecture?
Compliance cao
Audit dễ
Phân quyền rõ ràng
Phù hợp tổ chức lớn
Insight
Layered Architecture trong enterprise không xấu,
nhưng thường đi kèm delivery chậm và chi phí cao.
👉 PM/BA cần hiểu:
Chậm không phải do dev yếu mà do kiến trúc + governance
Kết luận: Architecture là tư duy, không phải sơ đồ
Layered Architecture tồn tại lâu không phải vì nó hoàn hảo, mà vì nó dễ bắt đầu.
Nhưng với PM / BA:
Kiến trúc không chỉ để “chạy được”,
mà để hệ thống còn sống được sau vài năm.
Hiểu Layered Architecture không phải để tránh dùng nó, mà để biết khi nào nó bắt đầu trở nên nguy hiểm.
Bài tiếp theo mình sẽ giới thiệu thêm Modular Monolith, đó là sự phát triển từ Layered Architecture, cũng như Event-Driven Architecture và sẽ có bài chia sẻ về Microservices.