Ở bài trước sau khi Start with why thì chúng ta đã có lý do cho việc tìm hiểu về Domain Driven Design rồi nên sang tới bài này chúng ta sẽ tiếp tục với câu hỏi Domain Driven Design là cái gì? Câu trả lời thì cũng không quá đơn giản và dễ dàng nhưng cũng không đến mức quá cao siêu và phức tạp như cách mà những chuyên gia trình bày trong các quyển sách viết về Domain Driven Design.
Đang xem: Domain driven design là gì
Trước khi đưa ra câu trả lời thì mình có một bức xúc muốn bày tỏ đó là mình rất ghét mấy thằng Tây viết sách về IT ( nó là ghét bọn Tây đơn giản là vì chưa có thằng Ta nào viết sách về mấy món này toàn Tây viết chứ không phải phân biệt gì cả ), cuốn sách nào cũng dài đến vài trăm trang mà thực chất thông tin có giá trị cô đọng lại chỉ có được đến vài trang và nhiều lắm là hai ba chục trang. Thời đại thông tin bay nhanh hơn tên lửa thì lấy đâu ra thời gian mà ngồi gặm nhấm hàng đống thông tin rác rưởi cố tình bôi vẽ ra cho nhiều để bán sách kiếm tiền và lấy danh tiếng. Thế nên các bạn lưu ý đừng mất thời gian vô bổ vào việc đọc sách một cách tuyến tính line by line đi từ đầu đến cuối, hãy nhớ rằng định luật Pareto ( hay còn gọi là định luật 80/20) luôn luôn đúng. Sách của bọn Tây di mọi rợ viết chỉ có nhiều lắm 20% thông tin là valuable còn lại toàn là thứ vẽ rắn thêm chân nên khi đọc sách chúng viết tốt nhất là chọn cách nhảy dù vào giữa khu rừng rậm và phải luyện cho mình kỹ năng lùng sục, thế nào rồi chúng ta cũng sẽ lôi ra được từ trong đó vài chục em thổ dân xinh tươi trong tình trạng nude sẽ phản ánh đúng bản chất trần trụi của vấn đề. Bây giờ mình sẽ show cho các bạn vài em như thế có thể giúp các bạn có cái nhìn khái quát gần gũi nhất về Domain Driven Desgin.
Để tránh có cái nhìn sai lạc trước tiên phải xóa bỏ ngay một số hình dung sai lầm thường thấy về DDD là DDD là một công nghệ mới hay là một Framework mới. DDD không liên quan gì đến công nghệ hay Framework là những thứ thuộc về tầng vật lý ( Physical View ) mà nó là một khái niệm thuộc về tầng logic ( Conceptual View ) khi chúng ta xây dựng một hệ thống phần mềm. Cụ thể hơn nó là một Design Pattern và hơn nữa đây là Design Pattern ở cấp độ kiến trúc của hệ thống Architectural Pattern , chúng ta cần rõ điều này để phân biệt với các Design Pattern nổi tiếng ở cấp độ class được viết trong sách của bọn bè lũ bốn tên ( Gang of Four ) . Nó cung cấp một cấu trúc thực hành ( Structure of practice ) và các thuật ngữ ( terminology ) giúp cho việc ra các quyết định thiết kế được hiệu quả hơn. Và vì nó tỏ ra hổ báo như thế nên chúng ta rà soát lại kiến trúc ngôi nhà mà nó vẽ ra một lần nữa xem tròn méo thế nào.
Các bạn cứ nhìn vào hình trên đây là sẽ hiểu về vai trò của Factory và Repository. Ở đây Gateway có thể nằm ở tầng Infrastructure và có thể là DAO hoặc cũng có thể là object truy cập vào một webservice ở bên ngoài.
Và để cho dễ nhớ về đám gạch đá ( bulding block ) để xây nhà theo kiến trúc DDD này thì chúng ta tóm tắt trong cái hình này cho dễ hình dung.
Data Transfer Object: Tuy không phải là một phần của DDD nhưng cũng đưa vào đây vì nó vẫn đường được sử dụng trong mô hình nhiều lớp, đơn giản nó chỉ là các Object không có logic và chỉ được dùng để truyền dữ liệu qua các layer khác nhau trong ứng dụng mà thôi.
Xem thêm: Văn HóA Là Gì ? KháI NiệM Và Ý NghĩA Về Văn HóA Văn Hóa Là Gì
Viết nhiều chữ quá cũng không hiệu quả, nên phần kết của cái bài đi tìm câu trả lời cho câu hỏi What Design Driven Domain là cái gì mình sử dụng cái hình này, nhìn vào đó ta có thể thấy được thought process ( tư duy thiết kế tổng quan ) của DDD được triển khai như thế nào. Có một số khái niệm chưa được giải thích sẽ bổng sung thêm khi có thời gian.