·
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…
·
TED Talks – Bài phỏng vấn với Sam Altman về Tương lai của AI – An toàn & Quyền lực
Tóm tắt những nội dung chính: Hội thoại giữa Chris và Sam tại TED xoay quanh các chủ đề về trí tuệ nhân tạo (AI), mô hình tạo hình ảnh và video, cũng như tác động của AI đối với sáng tạo, kinh tế, và xã hội. Dưới đây là tóm tắt nội dung chính…
·
DDD: Phần 8 – Các pattern kiến trúc trong Domain-Driven Design
Phần này này giải thích rõ sự khác biệt giữa logic nghiệp vụ (business logic) và các mẫu kiến trúc (architectural patterns). Trong khi các mẫu chiến thuật (tactical patterns) tập trung vào cách xây dựng logic nghiệp vụ, các mẫu kiến trúc quan tâm đến cách tổ chức tương tác và phụ thuộc giữa…
·
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 6 – Những Domain Model Patterns giải quyết business logic phức tạp
Xem lại phần 5: DDD [Part 5]: Transaction Script & Active Record – 2 patterns để giải quyết business logic đơn giản 📜 Lịch sử & nguồn gốc 🔹 Cuốn sách của Evans không chỉ nhấn mạnh khái niệm “Domain Model” mà còn giới thiệu tập hợp các mẫu thiết kế cụ thể (gọi là…
·
DDD: Phần 5 – Transaction Script & Active Record – 2 patterns để giải quyết business logic đơn giản
Xem lại phần 4: DDD [Part 4]: Mô hình hóa tích hợp giữa các Bounded Context trong Domain-Driven Design “Business logic là lý do phần mềm được xây ra.”Giao diện có đẹp, cơ sở dữ liệu có nhanh đến đâu cũng trở nên vô nghĩa nếu phần mềm không giải quyết đúng bài toán kinh…
·
DDD: Phần 4 – Mô hình hóa tích hợp giữa các Bounded Context trong Domain-Driven Design
Xem lại phần 3: DDD [Part 3]: Quản lý Domain Complexity: Khám phá Sức mạnh của Bounded Context trong Thiết kế phần mềm 🧠 Domain có 2 mặt: Problem Space vs Solution Space 🔍 Problem Space là gì? 🛠️ Solution Space là gì? Bounded Context & Mô hình 📌 Bounded Context không chỉ giúp bảo…
·
DDD: Phần 3 – Quản lý Domain Complexity: Khám phá Sức mạnh của Bounded Context trong Thiết kế phần mềm
Xem lại phần 2: https://minhphien.com/ddd-part-2-giao-tiep-va-ngon-ngu-chung-trong-domain-driven-design/ Trong hai phần trước, chúng ta đã hiểu rõ tầm quan trọng của ngôn ngữ chung (ubiquitous language) đối với việc giao tiếp giữa nhóm kỹ thuật và các domain expert trong môi trường phát triển phần mềm. Tuy nhiên, thực tế tại nhiều tổ chức, ngôn ngữ chung thường…
![DDD: Phần 9 – [Series] Communication Patterns trong Domain-Driven Design](https://minhphien.com/wp-content/uploads/2025/04/image-36.png)
