Lesson 1.1: Backend Design System là gì?

Thời lượng: 20 phút
Level: Beginner
Yêu cầu: Kiến thức REST API cơ bản

Mục tiêu bài học

Sau bài học này, bạn sẽ:

• Hiểu được định nghĩa chính xác của Backend Design System
• Biết 5 thành phần cốt lõi của một Backend DS
• Phân biệt được Design System với coding guidelines đơn thuần

Nội dung chính

1. Định nghĩa Backend Design System

Backend Design System là một tập hợp có cấu trúc các:

• Conventions: Coding standards, API patterns, naming rules
• Shared Libraries: Reusable packages cho các tasks phổ biến
• Templates: Boilerplate cho services mới
• Documentation: Living specs và examples
• Governance: Quy trình adoption và evolution

// Ví dụ: Một phần của Backend Design System
interface BackendDesignSystem {
  conventions: {
    naming: NamingRules;
    errorHandling: ErrorStandards;
    logging: LoggingFormat;
  };
  libraries: {
    httpClient: StandardHttpClient;
    validator: ValidationLibrary;
    logger: LoggingLibrary;
  };
  templates: {
    microservice: ServiceTemplate;
    lambda: LambdaTemplate;
  };
}

Tip: Design System không phải là documentation - nó là hệ thống sống được enforce bằng code, tests, và CI/CD pipelines.

2. Tại sao cần Backend Design System?

Vấn đề thường gặp khi KHÔNG có Design System:

Lợi ích khi CÓ Design System:

┌─────────────────────────────────────────────────────────┐
│                    TRƯỚC Design System                   │
│  Service A: { error: "Not found" }                      │
│  Service B: { message: "404", code: "ERR_404" }         │
│  Service C: { status: "error", reason: "missing" }      │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│                    SAU Design System                     │
│  Tất cả services:                                       │
│  {                                                       │
│    "success": false,                                     │
│    "error": {                                            │
│      "code": "RESOURCE_NOT_FOUND",                       │
│      "message": "The requested resource was not found"  │
│    }                                                     │
│  }                                                       │
└─────────────────────────────────────────────────────────┘

3. Năm thành phần cốt lõi

3.1. Conventions (Quy ước)

// ❌ Không có convention
function getUser(id) { ... }
function fetchUserById(userId) { ... }
function loadUserData(user_id) { ... }

// ✅ Có convention
function getUserById(userId: string): Promise<User> { ... }
function getOrderById(orderId: string): Promise<Order> { ... }
function getProductById(productId: string): Promise<Product> { ... }

3.2. Shared Libraries (Thư viện dùng chung)

// Thay vì mỗi service tự implement
import { createLogger, httpClient, validateRequest } from '@company/backend-core';

const logger = createLogger('user-service');
const response = await httpClient.get('/api/users');
const validatedData = validateRequest(schema, request.body);

3.3. Templates (Mẫu khởi tạo)

# Tạo service mới từ template chuẩn
npx create-service my-new-service

# Kết quả: Có sẵn folder structure, configs, health endpoint, logging, etc.

3.4. Documentation (Tài liệu)

• API guidelines với examples
• Error code catalog
• Architecture Decision Records (ADRs)
• Runbooks cho operations

3.5. Governance (Quản trị)

• RFC process cho thay đổi lớn
• Code review checklist
• Automated linting và validation
• Migration guides

Nguyên tắc then chốt

"Nếu không thể enforce bằng code hoặc automated checks, đó không phải là standard - đó chỉ là suggestion."

Nguyên tắc này là litmus test quan trọng nhất:

Thực hành

Bài tập 1: Audit codebase hiện tại

Mục tiêu: Tìm inconsistencies trong codebase hiện tại của bạn

Yêu cầu:

• List 5 pain points do thiếu chuẩn hóa
• List 5 cải tiến Design System có thể mang lại
• Ước tính thời gian tiết kiệm được

Template:

# Why We Need a Backend Design System

## 5 Pain Points hiện tại
1. [Pain point 1] - Ví dụ: "Mỗi service log theo format khác nhau"
2. [Pain point 2]
3. [Pain point 3]
4. [Pain point 4]
5. [Pain point 5]

## 5 Goals sau khi có Design System
1. [Goal 1] - Ví dụ: "Bất kỳ dev nào cũng có thể setup service mới trong 15 phút"
2. [Goal 2]
3. [Goal 3]
4. [Goal 4]
5. [Goal 5]

## ROI Estimate
- Thời gian onboarding hiện tại: ___ ngày
- Thời gian onboarding mục tiêu: ___ ngày
- Số lần duplicate code per month: ___

Tình huống thực tế

Scenario 1: Startup đang scale

Bối cảnh: Bạn là Tech Lead tại một fintech startup. Team từ 3 người giờ đã lên 15 người. Mỗi microservice được viết bởi người khác nhau, theo style khác nhau.

Vấn đề cụ thể:

• Mỗi service return errors theo format riêng
• Developers mới mất 2 tuần để hiểu codebase
• Debug cross-service issues cực kỳ khó vì logs không consistent

Câu hỏi:

1. Bạn sẽ bắt đầu chuẩn hóa từ đâu?
2. Làm thế nào để thuyết phục team adopt chuẩn mới khi họ đã quen với cách cũ?
3. Làm sao balance giữa "ship fast" và "build foundation"?

Câu hỏi phỏng vấn

Junior Level

Q1: Backend Design System là gì và tại sao startup nhỏ vẫn cần?

Q2: Liệt kê 3 thành phần quan trọng nhất của Backend DS?

Mid Level

Q1: Bạn sẽ introduce Backend Design System như thế nào vào một team đã có 10 microservices?

Senior Level

Q1: Design một governance process cho Backend Design System trong org 50+ engineers.

Tóm tắt

Những điều cần nhớ

Key Takeaways

1. Design System ≠ Documentation: Nó phải được enforce bằng code
2. Start small: Không cần full system ngay, bắt đầu từ pain point lớn nhất
3. Gradual adoption: Apply cho code mới, migrate code cũ dần

Checklist hoàn thành

• Hiểu được 5 thành phần của Backend DS
• Hoàn thành bài tập audit codebase
• Có thể giải thích difference giữa DS và coding guidelines
• Trả lời được câu hỏi phỏng vấn Junior

Tài liệu tham khảo

• Martin Fowler - Design Systems
• Stripe API Design
• Google AIP

Bước tiếp theo

Trong bài tiếp theo Lesson 1.2: Xác định phạm vi MVP, bạn sẽ học cách scope MVP đúng cách để không bị overwhelm khi build Design System.

Tiếp tục Lesson 1.2 →