Danh mục: Software Architecture

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à…

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…

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…

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…

Xem lại phần 1: https://minhphien.com/ddd-part-1-phan-tich-mien-nghiep-vu-trong-domain-driven-design/ “Thứ được đưa vào production không phải là tri thức của chuyên gia miền, mà là những gì lập trình viên hiểu (hoặc hiểu sai).”— Alberto Brandolini Khi phát triển phần mềm, chúng ta thường nhảy ngay vào viết code, tạo schema, vẽ luồng xử lý. Nhưng nếu bỏ qua…

Giới thiệu Trong lĩnh vực phát triển phần mềm, nhiều developer chỉ quan tâm đến việc viết code hoàn chỉnh và tối ưu. Tuy nhiên, Domain-Driven Design (DDD) nhắc nhở rằng để thiết kế hệ thống tốt, trước hết ta cần hiểu vấn đề của doanh nghiệp và môi trường vận hành của nó. Đó…