
·
Hướng Dẫn Review Code Hiệu Quả
Bài viết gốc: https://engineeringblog.yelp.com/2017/11/code-review-guidelines.html#when-reviewing-code Nếu bạn cần thêm tài liệu tham khảo về chủ đề này, hãy try cập: Jonathan Maltz, Kỹ Sư Phần Mềm 20 tháng 11, 2017 Chúng tôi đặc biệt coi trọng việc review code và cho rằng đây là yếu tố then chốt để xây dựng một tổ chức kỹ thuật (engineering)…

·
Software Architecture: Tách Monolith Thành Kiến Trúc Phân Tán
“Làm sao ăn hết con voi? Câu trả lời cổ điển: ăn từng miếng.Nhưng trong kiến trúc phần mềm, nếu ăn không khéo, con voi đó sẽ đè bạn chết trước khi bạn xong bữa.” 🧠 Khi Sysops Squad được “bật đèn xanh” Sau khi Addison và Austen được cấp trên gật đầu cho phép…

·
Software Architecture: Hiểu Đúng Về Coupling Trong Kiến Trúc Phần Mềm
🔗“Mọi thứ trên đời đều là độc dược, chẳng có gì không độc; chỉ liều lượng khiến nó trở thành thuốc hay độc dược.”— Paracelsus ☕ Một cuộc tranh luận quen thuộc Trong căn tin, vài kiến trúc sư của Penultimate Electronics đang bàn sôi nổi về microservices. “Tôi nghĩ ta nên dùng saga pattern…

·
Software Architecture: Khi “Best Practices” Trở Nên Vô Nghĩa
“Không có phát triển nào – cả công nghệ lẫn quản lý – có thể tăng năng suất đến mười lần chỉ trong một thập kỷ.”— Fred Brooks, No Silver Bullet (1986) 🌫 Khi “best practice” trở nên vô dụng Người làm công nghệ thường chia sẻ “best practice” – những công thức đã chứng…

·
Data-Intensive Application: Lựa chọn mô hình dữ liệu and ngôn ngữ truy vấn
📘 Tư tưởng chủ đạo: Wittgenstein nói: “The limits of my language mean the limits of my world”. Trong hệ thống dữ liệu, mô hình dữ liệu chính là “ngôn ngữ” mô tả thế giới đó. Việc chọn mô hình nào sẽ ảnh hưởng lớn đến cách ta tư duy, thiết kế và tối ưu…

·
DDD: Phần 12 – EventStorming – Mô hình hóa nghiệp vụ bằng cộng tác
“EventStorming là một hoạt động low-tech nhưng mang lại hiệu quả high-value.” 🎯 Mục tiêu của EventStorming 🧠 EventStorming là gì? 👥 Ai nên tham gia? 🔑 Chỉ nên từ 5–10 người để đảm bảo mọi người đều có thể đóng góp hiệu quả. 🧰 Cần chuẩn bị gì? Thành phần Vai trò 📄 Tường/bảng…

·
DDD: Phần 11 – Tiến hóa quá trình ra quyết định
“The only constant in life is change.” — Heraclitus DDD không chỉ là thiết kế cho hiện tại mà còn phải chuẩn bị sẵn cho tương lai, cho sự thay đổi đến từ: 🧱 1. Thay đổi loại Subdomain Kiểu chuyển đổi Động lực chuyển đổi Ví dụ Core → Generic Mất tính cạnh tranh…

·
DDD: Phần 10 – Design Heuristics – Chiến lược & chiến thuật
🧭 Design Heuristics là gì? Heuristic là quy tắc kinh nghiệm – không đảm bảo đúng trong 100% trường hợp, nhưng đủ hiệu quả để đưa ra quyết định trong tình huống cụ thể. Nếu bạn dịch từ “Heuristics” trong tiếng Anh – nó còn có ý nghĩa: Phương pháp thử – sai, rút kinh…
![DDD: Phần 9 – [Series] Communication Patterns trong Domain-Driven Design](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI2MDAiIGhlaWdodD0iMjYzIiB2aWV3Qm94PSIwIDAgNjAwIDI2MyI+PHJlY3Qgd2lkdGg9IjEwMCUiIGhlaWdodD0iMTAwJSIgZmlsbD0iI2NmZDRkYiIvPjwvc3ZnPg==)
·
DDD: Phần 9 – [Series] Communication Patterns trong Domain-Driven Design
Đây là chương đặc biệt quan trọng trong kiến trúc DDD vì nó mở rộng từ nội tại một Bounded Context sang giao tiếp giữa nhiều Bounded Context – một thách thức phổ biến trong hệ thống phân tán hiện đại. Xem lại phần 8 tại: DDD: Phần 8 – Các pattern kiến trúc trong…

·
DDD: Phần 7 – Event-Sourced Domain Model – Khi Dữ Liệu Kể Câu Chuyện Của Chính Nó
Xem lại phần 6: DDD [Part 6]: Những Domain Model Patterns giải quyết business logic phức tạp Trong hành trình phát triển phần mềm, một trong những thách thức lớn nhất chính là hiểu đúng và đủ về những gì đã xảy ra trong hệ thống — không chỉ trạng thái hiện tại, mà còn…






![DDD: Phần 9 – [Series] Communication Patterns trong Domain-Driven Design](https://minhphien.com/wp-content/uploads/2025/04/image-36.png)
