Domain Driven Design : Cái gì vậy ?

Bài đăng này đã không được cập nhật trong 7 năm

Là một newbie, mọi kỹ năng còn rất thấp, kinh nghiệm chưa có nhiều, code để chạy được đã là tốt lắm rồi làm sao dám bàn những chủ đề vĩ mô. Tuy nhiên, có một thời gian mày mò trên Google, mình biết đến một cụm từ 'DDD'. Mới đầu, mình cứ nghĩ là họ viết nhầm vì có một khái niệm gần gũi hơn là 'TDD'. Sau một vài lần click vào các link có cụm từ DDD, mình thử đọc nó xem thế nào. Một cái gì đó rất mông lung, trừu tượng, đơn giản là vì mình chả hiểu gì cả, đọc đi đọc lại nhiều lần, mày mò các kiểu nhưng thực sự nó khá xa vời với một người chưa có kinh nghiệm làm dự án thực tế. Tuy nhiên, mình cũng hiểu cơ bản tư tưởng của nó, vì vậy, mình mạn phép được share một số điều mình tìm hiểu được với mọi người. DDD là viết tắt của cụm từ: Domain Driven Design. Với các dự án nhất là outsourcing, chúng ta thường theo hướng : đọc spec và list ra tính năng -> chia nhỏ, phân công và estimate thời gian cho các task -> design database -> start coding. Tuy nhiên, theo cách tiếp cận phát triển dự án này, sẽ có thể gặp một số vấn đề:

Nghiệp vụ trong spec không rõ ràng, đầy đủ khiến cho developer mất nhiều thời gian hỏi, đôi khi hiểu nhầm spec -> sửa code.
Không có tầm nhìn bao quát tới chi tiết dẫn đến việc thiết kế model, sử dụng object, function không được tối ưu.
Khách hàng thường không biết tech, họ chỉ cần làm sản phẩm đúng ý họ. Trong khi đó, dev lại cần nghiệp vụ -> thiếu tương tác trực tiếp với khách hàng. DDD đề cao sự tương tác trực tiếp, thấu hiểu nghiệp vụ từ khách hàng tới dev. Tuy nhiên, như đề cập trên, khách hàng họ không biết tech, mà dev lại dùng chủ yếu ngôn ngữ tech và ngược lại. Vậy làm thế nào để khách hàng có thể truyền đạt hết, rõ nghiệp vụ cho dev và dev nói chuyện với khách hàng một cách dễ hiểu để tương tác giữa hai bên được tốt nhât ? DDD giúp ta giải quyết các vấn đề này bằng việc tập chung vào nghiệp vụ. DDD cung cấp cho chúng ta cấu trúc phát triển dự án, những công nghệ giúp cho việc thiết kế, phát triển dự án tập chung vào nghiệp vụ đối với các dự án có nghiệp vụ phức tạp. Qua quá trình tìm hiểu, mình thấy một số concept quan trọng:
1. Domain: Ở đây có thể hiểu đơn giản là miền nghiệp vụ bao gồm tất cả kiến thức, tầm ảnh hưởng, các khái niệm trong lĩnh vực liên quan tới nghiệp vụ. Việc hiểu rõ về domain sẽ giúp chúng ta xây dựng hệ thống tốt hơn, đáp ứng đúng yêu cầu. Tuy nhiên, làm sao để hiểu được domain ?
2. Ubiquitous language: Để trả lời câu hỏi trên, chúng ta có "Ngôn ngữ chung". Nó là tập hợp của các từ ngữ thông thường trong lĩnh vực nghiệp vụ. Tuy nhiên được diễn đạt một cách dễ hiểu, gần gũi để cả dev và customer hiểu và nói chuyện được với nhau bằng ngôn ngữ này. NOTE: không dùng ngôn ngữ chuyên môn trong tech.
3. Entity: Đại diện cho một đối tượng trừu tượng trong nghiệp vụ. Có thể hiểu đơn giản như Model với các đặc tính để nhận biết (attribute).
4. Repository: Chắc hẳn chúng ta không còn xa lạ với cụm từ này. Áp dụng repository design pattern trong DDD đem lại hiệu quả vô cùng lớn.
5. Domain service: Chính là các phương thức nơi cài đặt logic nghiệp vụ là cách để thực thi actions, operations and activities. Mình xin phép được dùng viết tại đây, bởi vì mình chưa đủ kiến thức để nói tiếp. Mình sẽ cố gắng học hỏi tìm hiểu thêm để tiếp tục topic này ! Cảm ơn mọi người đã quan tâm.

Mục lục