Map of Content

Tran Van Ngoc|
#type/concept#status/permanent

TL;DR

Một node (ghi chú) đặc biệt đóng vai trò làm “mục lục động” để gom nhóm và điều phối các Atomic Notes rời rạc. Giúp não bộ có được cái nhìn toàn cảnh (Bird’s-eye view) chống lại sự hỗn loạn khi hệ thống Zettelkasten phình to.

Core Concept

  • Tư duy từ dưới lên (Bottom-up): Đừng thiết kế MOC từ trước. Hãy cứ viết các ghi chú độc lập. Khi các ghi chú đạt đến một “khối lượng tới hạn” (Critical Mass) và có chung một ngữ cảnh, lúc đó MOC mới được sinh ra để xâu chuỗi chúng lại.
  • Tính đa hình (Polymorphism): Khác với cấu trúc thư mục tĩnh (một file chỉ nằm trong một folder), MOC hoàn toàn linh hoạt. Một Atomic Note tên là Modular_Monolith có thể được link cùng lúc vào Software_Architecture_MOC và Startup_Tech_Stack_MOC.

Practical Implementation

  • Trade-offs (Nợ bảo trì - Maintenance Debt): Tạo MOC thì dễ, nhưng giữ cho nó “sống” thì khó. Nếu em viết thêm note mới mà quên không cập nhật link vào MOC tương ứng, MOC đó sẽ trở thành “Mã chết” (Dead code), không còn phản ánh đúng kho tàng kiến thức hiện tại.
  • Tử huyệt (The Folder Fallacy): Sai lầm kinh điển là dùng MOC như một cái thùng chứa để liệt kê link một cách vô hồn (như kiểu copy-paste list file). MOC xịn phải có “ngữ cảnh”. Em phải chèn các dòng text giải thích TẠI SAO các link này lại đứng cạnh nhau.
  • Code Snippet (Cấu trúc một MOC chuẩn):
# ️ Software Architecture MOC

_Bản đồ các mẫu thiết kế cấu trúc hệ thống Backend._

## 1. Core Patterns

Sử dụng khi bắt đầu setup project mới:

- [[Layered_Architecture]]: Dành cho team nhỏ, dễ hiểu nhưng dễ rác.
- [[Modular_Monolith]]: Dành cho scale vừa, chia theo Domain.

## 2. Communication

Giữ cho các module không đấm nhau:

- [[Public_Interface_Pattern]]: Tạo cổng giao tiếp an toàn.
- [[Shared_Module_Dependency_Rule]]: Ép luồng dữ liệu một chiều.

Related Notes:

  • Nền tảng tạo ra các hạt kiến thức nhỏ để đắp vào MOC: Zettelkasten_Method
  • Tiêu chuẩn của một hạt kiến thức: Atomic_Note