1. The Hook: architecture không phải nhãn sản phẩm
Hỏi một team đang dùng architecture gì, câu trả lời thường giống catalog công nghệ: microservices, event-driven, CQRS, Kubernetes, thêm hexagonal architecture cho đủ bộ. Tất cả có thể đúng nhưng vẫn giải thích rất ít.
Một hệ thống thật có thể là modular monolith ở deployment boundary, hexagonal bên trong vài module, event-driven giữa các domain và chỉ dùng CQRS nơi áp lực đọc–ghi tách biệt. Các thuật ngữ này không cạnh tranh trên cùng một trục. Chúng mô tả những lực khác nhau.
Architecture không phải một pattern. Nó là hình dạng tích lũy từ các quyết định về boundary, dependency, communication, state, execution, deployment, policy và change. Architecture DNA Compass là heuristic đề xuất để đọc hình dạng đó. Nó không phải industry standard, maturity score hay vật thay thế architectural judgment.
Ẩn dụ này là điểm cần giữ: compass hỗ trợ judgment dưới áp lực; nó không biến architecture thành một đích đến hay điểm số duy nhất.
Cách nhìn này bổ sung cho các công cụ đã có. C4 model cung cấp nhiều mức zoom cùng dynamic và deployment view. arc42 tách building block, runtime, deployment, quality, risk và decision. Compass đứng trước chúng: hỏi cần quan sát gì trước khi chọn cách document hoặc evaluate.
2. Core architecture: tám dimension, không phải tám silo
Decomposition và dependency
Decomposition hỏi hệ thống có những gì: system, service, module, component, worker và store. Boundary chỉ có ích khi cô lập responsibility và giới hạn blast radius của thay đổi. Đếm folder không phải phân tích architecture.
Dependency hỏi ai biết ai và thay đổi lan truyền thế nào. Direction, fan-in, fan-out, cycle, shared contract và shared state thường nói thật hơn repository tree. Hệ thống 100 module với dependency kỷ luật có thể dễ đổi hơn hệ thống 15 module import lẫn nhau.
Communication và data
Communication không dừng ở HTTP hay queue. Nó gồm sync/async, delivery guarantee, ordering, timeout, retry, idempotency, backpressure, schema compatibility và failure semantics. Thay function call bằng event bus là thay quan hệ của hệ thống với thời gian và partial failure.
Data bắt đầu từ ownership, không phải nơi lưu. Cần trace transaction boundary, consistency, replication, derived state, cache, index, retention, migration, lineage và synchronization. Shared database thường bóc trần những boundary chỉ tồn tại trên slide.
Execution và deployment
Execution hỏi công việc diễn ra theo thời gian thế nào: request/response, scheduled job, consumer, workflow, retry loop, human approval, long-running process hay agent loop. Box không giải thích được resumability, compensation hoặc recovery.
Deployment ánh xạ logical component sang process, container, node, cluster, region và network. Một logical service không nhất thiết là một container; một container cũng không phải availability strategy.
Policy và evolution
Policy bao gồm authentication, authorization, trust boundary, tenant isolation, sandbox, secret, quota, audit, approval và cost limit. Trong banking, healthcare, multi-tenant cloud hoặc autonomous-agent platform, policy có thể định hình toàn bộ thiết kế.
Evolution kiểm tra liệu thiết kế đẹp hôm nay có sống được với thay đổi ngày mai: API/schema versioning, compatibility, extension point, feature flag, rolling migration, deprecation và data migration. Diagram là snapshot; architecture là một hệ constraint đang sống.
3. The execution loop: đọc một codebase xa lạ
Đừng bắt đầu bằng vài file ngẫu nhiên. Hãy dựng hypothesis rồi ép repository và runtime xác nhận hoặc bác bỏ nó.
Một vòng đọc thực dụng gồm:
- Xác định system boundary, actor và external system.
- Lập inventory building block chính, chưa cần đọc mọi implementation.
- Dựng dependency graph, tìm cycle và shared state.
- Trace communication qua từng boundary quan trọng.
- Theo một business entity từ lúc tạo, sửa, copy, index đến xóa.
- Trace ba đến năm flow, gồm failure recovery chứ không chỉ happy path.
- Map logical component sang runtime và region.
- Tìm boundary của trust, tenant, secret, quota, audit và approval.
- Tìm mọi thứ được version—hoặc nguy hiểm hơn, không được version.
Workflow này phù hợp với khuyến nghị của arc42: tập trung chi tiết vào building block quan trọng, bất ngờ, rủi ro, phức tạp hoặc biến động thay vì theo đuổi sự đầy đủ vô điều kiện.
4. The nightmare: biến compass thành độ chính xác giả
Mỗi dimension có thể được xem qua ba pressure trên thang 0–5:
- Complexity: Có bao nhiêu mechanism, state, dependency và moving part?
- Criticality: Khi thất bại, ta mất một job, tiền, dữ liệu, niềm tin hay cả service?
- Change rate: Requirement, contract, team hoặc công nghệ đổi nhanh đến đâu?
Một heuristic tùy chọn để triage:
$$ \text{Attention} = \text{Criticality} \times \frac{\text{Complexity} + \text{Change Rate}}{2} $$
Nó xếp thứ tự attention, không đo chất lượng architecture. Radar lớn không đồng nghĩa architecture tệ. Air-traffic control đương nhiên chịu nhiều pressure hơn landing page.
Failure mode lớn nhất là score theatre: architect tranh luận 3.7 hay 4.1 nhưng không có evidence. Mỗi score cần dấu vết—dependency cycle, shared package, trace span, retry path, incident, schema churn, API version hoặc Git change frequency.
Failure mode thứ hai là tối ưu fingerprint. Giảm complexity có thể làm giảm reliability; isolation mạnh hơn có thể tăng latency và operating cost; evolution nhanh có thể làm yếu compatibility. SEI Architecture Tradeoff Analysis Method đánh giá architecture theo quality-attribute goals và làm lộ risk cùng trade-off. Vì vậy Compass cần một North Star nằm ngoài radar.
5. The architect’s fork: document, evaluate hay instrument?
Hướng A — onboarding snapshot nhanh
Dùng tám dimension để nén điều đã biết và chưa biết. Phù hợp khi acquisition, incident handover hoặc vừa bước vào repository lớn. Output là bản đồ câu hỏi, không phải phán quyết.
Hướng B — architecture review chính thức
Dùng Compass để tìm pressure, sau đó chuyển sang C4 hoặc arc42 để document và ATAM để đánh giá trade-off theo scenario. ISO/IEC 25010:2023 cung cấp vocabulary chuẩn cho product quality; Compass không thay thế nó.
Hướng C — architecture observability
Tự động hóa evidence: dependency graph và cycle cho Dependency; service call và event topic cho Communication; schema và lineage cho Data; trace và workflow definition cho Execution; IaC và topology cho Deployment; API version và change frequency cho Evolution.
Đích đến có giá trị không phải radar cập nhật sáu tháng một lần. Nó là instrument panel thay đổi cùng hệ thống và làm architectural drift lộ diện.
Nếu cần xem cách quality goals được chuyển thành câu hỏi đánh giá thực tế, webcast của Felix Bachmann tại SEI, Architecture Evaluation: A Tool for Designing Systems That Meet Users’ Needs, là video đáng xem. Giá trị của nó nằm ở cầu nối từ một lần review ATAM sang continuous design feedback—cũng là bước Compass cần để trở thành instrumentation thay vì workshop theatre.
Câu hỏi thay thế cái nhãn
Hai hệ thống cùng gọi mình là “microservices” có thể mang DNA đối nghịch. Hai hệ thống khác stack lại có pressure profile gần giống nhau. Câu hỏi hữu ích không còn là “Architecture này tên gì?” mà là:
Hệ thống đang chịu lực ở đâu, outcome nào quan trọng nhất, và evidence nào nói architecture cần tiến hóa?